How to return stack Trace to Client in MULE..? - exception

Does anybody know how to print full stack trace on the Browser, when a Runtime Exception occurs in MULE..??
When a runtime Exception occurs, MULE throws a 500 Server Error to the client , but shows no details to the client. It prints the whole stack trace in Console or Log Files (like the following) :
Root Exception stack trace:
java.sql.SQLException: Invalid column name
at oracle.jdbc.driver.OracleStatement.getColumnIndex(OracleStatement.java:3677)
at oracle.jdbc.driver.OracleResultSetImpl.findColumn(OracleResultSetImpl.java:2749)
at oracle.jdbc.driver.OracleResultSet.getString(OracleResultSet.java:494)
+ 3 more (set debug level logging or '-Dmule.verbose.exceptions=true'
for everything)
Can i show the same stack Trace on the Browser (to the client)..??
And if possible , then also tell me how to switch ON or OFF printing of Stack Trace on Browser..??
(It may be possible that sometime in future , i dont want to show stack trace on browser)

Yes this is possible. I assume you are using a regular HTTP endpoint and this is a REST type service(?) If so, you can simply put a try/catch around the code causing the exception and return whatever text you want.
There are also exception strategies (http://www.mulesoft.org/documentation/display/MULE3USER/Error+Handling) for doing more sophisticated error handling, but it sounds like you are looking for the simple answer above.
If this doesn't answer your question, please provide more info about your mule config and the service that is raising the exception.

There is nothing out of the box in Mule to do that. You have to implement an exception handler that will format the stacktrace in the Message exception payload and return it to the caller.
In your case, the HTTP transport has a particularity that can be found in the HttpMessageReceiver code:
try
{
conn.writeResponse(processRequest(request));
}
catch (Exception e)
{
...
conn.writeResponse(buildFailureResponse(request.getRequestLine().getHttpVersion(), httpStatus, e.getMessage()));
This means that when an exception crops-up to the top level, the creation of the failure message response is not customizable: you get this pretty technical message back and that is all.
I see two options to solve your problem:
sub-class HttpMessageReceiver and make the response message customizable in your version,
drop the HTTP transport in favor of the Jetty one (look at the bookstore example) and customize the response error messages at the web container level.

Related

Micronaut: Proper logging of "uncaught" Exceptions to not appear on System.err

I've a question regarding capture of "uncaught" exceptions, which appears with stack trace on System.err, circumventing logging configuration: All the other log messages appear properly formatted on System.out (JSON-formatted in my case). But this doesn't happen with Exceptions and stack traces "logged" to System.err!
I've recognized this to happen under at least two circumstances:
Asynchronous execution of tasks (HTTP requests in my case) via ExecutorService (as mentioned in "Scheduled Tasks" chapter). I've added #Retryable annotation to the method; but after all retries fail, "final" Exception thrown by last unsuccessful retry appears on System.err with its stack trace (the other ones thrown by earlier failed retries do not appear, seems they are caught by retry "mechanism" under the hood).
With Exceptions thrown by failed Health indicators (they are implemented by subclassing AbstractHealthIndicator).
I've tried implementing my own TaskExceptionHandler, replacing the default one (also mentioned in "Scheduled Tasks" chapter); and/or by adding System.setErr(System.out) in main method before building/setup of Micronaut Application Context. But nothing seems to help as my test cases attest.
Have I missed a chapter in Micronaut's documentation?
Thanks for any hints.
Regards
Christian
My wager is that Micronaut doesn't provide tools for setting a global uncaught exception handler because that's governed by the wider JRE. We've solved the problem in a few of our services with Thread.html#setDefaultUncaughtExceptionHandler by doing something like this at application startup:
Thread.setDefaultUncaughtExceptionHandler((t, e) -> logger.error("Uncaught exception", e));

Actual exception is not getting logged in MVC when host in IIS

I am running one MVC application where i found one exception in specific method. I will provide here complete details about it.
I am loading some third party grid control from view. to load it i used below code:
#{Html.RenderAction("MasterGridAction", "MyController");}
Now when i access this report from development then this view load and it hits this action method where i used some piece of code there it is throwing error, To catch the error i used try catch block in the method where in catch section i used below code to throw the actual exception like below:
catch (Exception ex)
{
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Capture(ex).Throw(); throw;
}
When exception get catched it sends this to the Application_Error method in global.asax page where i used below code to find out the actual exception like below:
void Application_Error(object sender, EventArgs e)
{
HttpServerUtility server = HttpContext.Current.Server;
if (server.GetLastError() != null)
{
Exception exception = server.GetLastError();
if (exception.GetBaseException() != null)
{
exception = exception.GetBaseException();
ExceptionType(server, exception);
}
else
{
ExceptionType(server, exception);
}
}
}
In this ExceptionType method i get the exception stack and log to the file using "Log4Net". After logging to the file i could see the exception in notepad like below:
Object reference not set to an instance of an object.
Source File: /MyController/MasterGridAction
Stack Trace:
at 3D.Controllers.MyController.MasterGridAction() in D:\MyUser\3D_MVC\Application\3D_OnlyRelease\3D\Controllers\MyController.cs:line 405
--- End of stack trace from previous location where exception was thrown ---
As we can see in above exception it is clearly shown the line number also where this exception get caught.
But once i host this application in IIS server and access the same page then i could see the logged file
There it shows exception like below:
Exception Message: Object reference not set to an instance of an object.
Stack Trace: at 3D.Controllers.MyController.MasterGridAction()
--- End of stack trace from previous location where exception was thrown ---
As you can see the logged exception of IIS server is not having much information when compare to other exception details.
Am i missing anything there to get the complete exception when host in IIS?
Please suggest.
As you can see the logged exception of IIS server is not having much information when compare to other exception details.
This could be because you don't include the PDB files in production.
It might not be a great idea to include them, since that way one can reverse engineer you app with more precision if they hack your server, but it is up to you to decide. I have seen organizations that include them in their production environments.
Try publishing and deploying on a test environment with and without the PDB files to verify this.

Breeze EF6 SaveChanges doesn't propagate exceptions

In the EFContextProvider (EF6) SaveChangesCore method, the exception handling looks like this:
} catch (Exception e) {
while (e.InnerException != null) {
e = e.InnerException;
}
throw e;
}
This throws only the most internal exception and hides the relevant information revealed by the external exceptions.
When the SaveChanges process goes through multiple layers the next direct layer exception is lost, and only the last exception in the chain is thrown. It doesn't allow to handle well the exceptions for the caller.
Updated Post
As of Breeze 1.4.6, any .NET Exceptions thrown on the server are now available in their original form in the httpResponse.data property of any async breeze result. Breeze will still drill down to extract a "good" error message, but will no longer obscure the initial exception.
Original Post Below -------------------
It's an interesting point. The reason we did this was because most client side apps aren't written to navigate thru the exception chain and we wanted to expose the most 'relevant' error to the client. Most of the apps we looked at just exposed the client "error.message" property directly and with EF errors this was almost always useless.
However, your point is well taken. I think what we need to do is create a new Exception that has a top level message that is the innermost exception message but still expose the entire exception chain for those that want to drill. I've added an internal feature request for this and will try to get it into a near term release ( probably not the next one because we are already in testing for that one).
And thanks for the input.

AS3, Flash: Accessing error messages text in code

I'm working on some flash app. Now, to test customer side of it I can use Flash Player debugger version that will save logs and show error messages. When it's deployed on the customer side - they will have a regular Flash Player version which means I will have no access to error messages if errors will happen. So I would like to equip it with some tool that would capture all of my trace messages in code and errors text. As for trace messages that's fairly simple, I just override the function in my code so it sends a POST request with trace message to a logger server, but how can I get a hold of the error message? Is there a known approach to this or some trick that somebody can suggest?
You can install the debug version of flash as your browser's default (in Chrome, you must disable the built-in player), so if you wanted to test user experience and debug, this would be the ideal solution.
However, to answer your question: there's no method for universally catching all errors, and redirecting them (that I know of). You'd have to encapsulate problem code ahead of time with try...catch statements, and send the property back on catch. For example:
try {
this["foo"]();
} catch (e:Error) {
trace(e);
}
In the debug version, the traced value would be TypeError: Error #1006: value is not a function. And while the standard version will only output TypeError: Error #1006, (a notably less descriptive error), what we're missing is any reference to where the error occured. To get this, we need to use Error.getStackTrace() to see the call stack and the line where the error occurred. In debug, this outputs the following:
TypeError: Error #1006: value is not a function.
at Shell_fla::MainTimeline/init()[C:\Projects\shell.as:91
In the standard client, we get a dissapointing null. In short, you cannot get any valuable info from the client versions.
The best advice I can give is to write around your problem code with your own custom error reports. For example, catch IO errors and trace the file it failed to load, or if you're expecting an object.foo, first try if (object.hasOwnProperty("foo")) { // do something } else { trace("foo not found in " + object.name) }. Code defensively.
Cheers,
I've discovered this post on StackOverflow:
How to catch all exceptions in Flex?
It answers my question, strange that I haven't ran into it while I was googling prior to asking.

How do I log a general exception to the Event Log?

I have a windows service, in which I want a top level try-catch that catches any otherwise unhandled (or bubbled) exception, logs it to the Event Log and then swallows it so the service keeps running. However, I can't find any overload to System.Diagnostics.EventLog.WriteEntry that takes an exception as a parameter - is there no way to just give the event log the exception and let it parse out the message on its own?
Unfortunately there is no standard way of just passing the Exception to the Eventlog, built in to the .NET framework.
To have an exception written to the EventLog with the smallest development effort, you would need to write something like:
EventLog myLog = new EventLog();
myLog.Source = "Your Source";
myLog.WriteEntry(exception.ToString(), EventLogEntryType.Error);
But normally you would try to do some formatting of your exception.