GWT Not showing root call trace on click exception - java

When handling a click event and an uncaught exception is thrown the console does not show the actual line of code where the exception is triggered. Instead, it looks like this:
Throwable.java:121 Uncaught Error: com.google.gwt.event.shared.UmbrellaException: Exception caught: (TypeError) : Cannot read property 'getNotificationsShortcuts_0_g$' of null
at iOi_g$.cve_g$ [as createError_0_g$] (Throwable.java:121)
at iOi_g$.mve_g$ [as initializeBackingError_0_g$] (Throwable.java:113)
at iOi_g$.Yue_g$ (Throwable.java:74)
at iOi_g$.Cve_g$ (Exception.java:33)
at iOi_g$.Kve_g$ (RuntimeException.java:33)
...
If I try/catch the code where the exception is thrown and print the caught exception by getting all the StackTraceElement items from e.getStackTrace(), it seems that the stack trace is displayed correctly (the root in my lines of code is displayed):
TypeError: Cannot read property 'getNotificationsShortcuts_0_g$' of null
at VCn_g$.fDn_g$ [as loadSavedShurtcuts_0_g$] (EMaterialNotificationsHeaderView.java:483)
at BCn_g$.HCn_g$ [as loadSavedShurtcuts_0_g$] (EMaterialNotificationsHeader.java:37)
at fFn_g$.gFn_g$ [as build_0_g$] (SDemoNotificationsHeader.java:51)
...
Is there a way to show set the logs so that the root call trace of the exception is displayed correctly when an event is triggered?

If an exception is directly caught, you will see the full stack trace. If an exception simply wraps another single exception, generally you'll see the stack trace as well.
But the UmbrellaException indicates that some event was going off when that exception was thrown. The event didn't just stop because of the exception (which would then cause other handlers to miss out on it), but instead the exception was noted, and the other handlers invoked. Once they were all finished, an UmbrellaException gets thrown, containing all of the exceptions that happened during the course of trying to fire that event.
Often this will only wrap a single exception, but the result is the same - the umbrella exception informs you that something went wrong, and the event finished informing all of its handlers, and then this was thrown to say that something went wrong.
If you are seeing this in your UnCaughtExceptionHandler (UCEH), then there was no try/catch around the fireEvent call itself.
Whether you catch it in the UCEH or in some other try/catch, once you test if it is an UmbrellaException, you can call exception.getCauses() to read all of the exceptions that occurred, and individually log each of them.

Related

How to log the error message when OutOfMemoryError occurs

I have an OOM error(Perm Gen is full), problem is when I am logging the error message into the log file, error occurs while the classloader is loading the exception handling class.
You shouldn't handle errors as your application is in abnormal state:
https://docs.oracle.com/javase/7/docs/api/java/lang/Error.html
Differences between Exception and Error
This answer explains scenario where you might want to do it though:
Catching java.lang.OutOfMemoryError?
You can either throw this error to handle where you're using it or you can put a try catch block around your logic(code) and you can log the error inside the catch or finally block.

JavaFX: How to show Alert without Stage for testing?

I use JavaFX for a GUI that waits for some user's input and tries to process that input. In case of any exception a javafx.scene.control.Alert is opened to present the exception to the user. The call for that Alert is done in the method that handles the exception.
This method is supposed to be tested: For a special input, check if the right exception is thrown. The right exception is actually thrown and the handling method is called, but now here's the problem: In the test case there is no real Application running and no Stage created. Apparently because of that the creation of the Alert-dialog throws the exception:
java.lang.IllegalStateException: Toolkit not initialized
at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:273)
at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:268)
at com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:550)
at com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:512)
at javafx.scene.control.Control.<clinit>(Control.java:87)
... 46 more
That causes the test to fail because now another incorrect exception is thrown.
So: Is there any way to show the Alert without having a Stage?

eclipse console doesn't show the exception

"The default handler displays a string describing the exception, prints a
stack trace from the point at which the exception occurred, and terminates the program."
But this doesn't happen. Every time i intentionally create a DivideByZero exception but provide no exception handler, the default handler should have displayed a string with stack trace but my console is empty and program is not terminated only exception it shows is in debug panel. It may be small problem but every where i look the exception should have been printed in console but myconsole is empty.
I use eclipse neon.
Update from comment:
public class Example {
public static void main(String args[]){
System.out.println(10/0);
}
}
This should give ArithmeticException but there is nothing displayed at console.
If you Run the program, it will print stacktrace.
If you Debug the program, the debugger will (by default) halt execution when an uncaught exception is thrown, but it will (by default) not show the exception. Select Resume (F8) to continue execution, and the program will end and print stacktrace.
If you don't intend to debug the program, choose Run to start the program, not Debug.
If you want to debug, but don't want to halt execution on uncaught exception, open Window > Preferences, go to Java > Debug, and uncheck Suspend execution on uncaught exceptions.
If you still want to halt execution on uncaught exception, but you also want to actually see the exception, open Window > Preferences, go to Java > Debug, and check Open popup when suspended on exception. Source: Inspect current exception in Eclipse debugger?
Note: The above is from Eclipse Mars.2, not Neon, but should be the same.

Should we log the stacktrace for managed exception?

I made many research on this subject without found a real answer.
Try to imagine a program which execute a multi thread calling a Callable.
For that, we launch an ExecutorService with a specific timeout which invoke all process.
So we have a try...catch block with multiple exception :
CancellationException for a timeout
ExecutionException if an exception is raised in the thread
InterruptedException for an abrupt stop...
Is the philosophy to log an message only, or to log the message and the throwable (so the stacktrace) ?
To sum up, should we do this :
} catch (CancellationException ce) {
logger.error("Timeout. Process cancelled", ce);
}
or just log the message error ?
Is stacktrace considered to appear only for bugs ?
Thank you.
For coding you should stick with the following pattern:
} catch (CancellationException ce) {
logger.error("Timeout. Process cancelled", ce);
}
The reason is that the Throwable captures the complete context of an error. If you omit parts of that context from the logger you'll never be able to access it later on if you need it. Even the Throwable class included with Java has been modified over time to include things like chained and suppressed exceptions. So even if you only want the message from this throwable you still might want to see the full stack traces for suppressed exceptions and exceptions causes.
On the output side, I think you can make that case that for some exceptions the stack trace is not important. In some cases the target audience must not or does not want to see exception stack traces. For these cases should leverage the features of the framework to change the published output to please the target audience. If the needs change over time you can tweak logging configuration without having to fix the application code.

Eclipse breaks on processWorkerExit

After serving a few requests my eclipse has started breaking on processWorkerExit() method.
As per this link I know how to suppress the breaking of eclipse but is there any reason why the code is breaking on this line. Can there be a memory leak in such a case?
Tomcat 7.0.27
Eclipse 3.7.2
JDK 7.0.02
Answer is here: OpenJDK breaks on processWorkerExit with no breakpoint
In debug mode in eclipse by default, break on uncaught exceptions is
checked. Since you don't have a catch method here, it's likely that an
uncaught exception is being thrown and the debugger is breaking for
you immediately before the exception is thrown. You can turn it off in
preferences under Java->Debug.
The reason the debugger is stopping on that line is because there is an exception being thrown by the code within the try{} block, and that particular line of code is the next executable line of code after the exception is thrown. You can almost certainly see the stack trace of that exception in the console window, because by default an uncaught exception that bubbles up to Thread.run() will be sent to stderr.
As for your question about whether there can be a memory leak (or more likely, this being Java, a resource leak): the answer is yes, there could be. But there is nothing in that code to indicate that there is. If there were such a leak, it would almost certainly be because there is incorrect exception handling inside the task implementation.
I had this same problem. It breaks in your try/catch clause if you have one if you don't log the exception. Try inserting a breakpoint or output to LogCat like this :
try
{
//HERE I'VE PUT ALL THE FUNCTIONS THAT WORK FOR ME
Log.e("tag", "Sth passed!");
}
catch (Exception e)
{
//The task failed
Log.e("tag", e.getMessage());
}
If you don't have try/catch block put it like in above code. In LogCat you can see the last line of code that was run before exception it will help you to locate the error in your code just like this :
08-28 05:49:52.321: E/SQLiteDatabase(834): at java.lang.Thread.run(Thread.java:841)

Categories

Resources