JDK-8113119 : LauncherImpl inner class catches all exceptions
  • Type: Bug
  • Component: javafx
  • Sub-Component: application-lifecycle
  • Affected Version: fx2.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2011-05-17
  • Updated: 2015-09-04
  • Resolved: 2011-07-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
fx2.0Resolved
Related Reports
Duplicate :  
JDK-8113171 - Application exceptions should be thrown to the caller of the launch method
Relates :  
JDK-8113171 - Application exceptions should be thrown to the caller of the launch method
Relates :  
JDK-8088773 - JavaFX does not fully support Java UncaughtExceptionHandler
Relates :  
JDK-8100937 - Allow application to catch exceptions thrown by FX application thread with an UncaughtExceptionHandler
Description
We are using the standard Java exception handling mechanism which allows you to install a default exception catcher for uncaught exceptions occurring on a thread using this method

Thread.setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler)

Even though our default exception handler is installed properly on the thread which Java FX uses to invoke our application's start() method, exceptions which occur in our code never end up at the UncaughtExceptionHandler.

From the stack trace I can see that our application start() method is invoked by the innerclass LauncherImpl$3 in its run method at line 92. The exception passes through our application start() method but it is caught by Java FX inside LauncherImpl and consequently the Java default exception handling mechanism is incapacitated.
Comments
In all three application modes, the launcher always catches exceptions thrown by the Application constructor and the init(), start(), and stop() methods. These exceptions are already rethrown to the caller of the application launcher. We do not plan to do anything further, since this is the expected behavior for most applications. An application that want to catch exceptions from the init(), start() and stop() method should wrap them in a try/catch block. So the problem isn't that LauncherImpl catches all exceptions. It does, but that isn't the real issue. The real limitation you are facing is that you need is the ability to catch uncaught exceptions in the JavaFX Event Dispatcher, either as the result of an input event handler, and animation pulse, or as the result of an exception in a Platform.runLater Runnable. I can see how this would be useful, but that is a feature request that is out of scope for this release. I have filed a new issue, RT-15332, to track this feature request.
26-07-2011
I have taken the liberty of reopening this issue, as it contains more details than issue 13602, which this issue has been said to duplicate. Issue 13602 only speaks of not getting an exception, while 13560 (this issue) and its comments requests support for the Java 5+ UncaughtExceptionHandler mechanism, which is very important to my company. I hope you agree that there is a benefit in keeping 13560 open, while the less detailed 13602 could (perhaps) be closed as a duplicate of 13560.
25-05-2011
This bug has proven to be a real time consumer. Everytime we run into an exception in an event handler, our application just does nothing. We really, really need to have support for the standard way of catching unhandled exceptions, so the developer can react to them, log them, etc.
25-05-2011
Hi Kevin If that is the case, I think we have spotted a design problem. All kinds of applications need to take special care of unhandled exceptions. In our app, for instance, we wish to present the user with a dialog window, telling the user that we are sorry for the inconvenience, and that a bug report has been filed, and we expect to look at the error shortly. As you know, unhandled exceptions can be a symptom of an application moving from a stable to an unstable state, which is why certain critical applications will have to shut down, if an unhandled exception occurs. They can only do so, if there is a way to detect unhandled exceptions. Java has had the Thread.UncaughtExceptionHandler class since 2004, and it has worked with Swing for years both with the Swing UI thread and any other program threads. Changing this API is definitely not something I would recommend, and I do not think there is any good alternative but to support this standard approach. Of course, you could introduce a new way for developers to hook in to the stream of unhandled exceptions, but is that not a bit like reinventing the wheel? I strongly recommend you consider this carefully. Yours Randahl
24-05-2011
You should be aware that in most cases, you won't be able to rely on exceptions being uncaught. For Applets and Java Webstart applications, as well as apps packaged up to run using the standalone Main launcher, the exception will always be caught by the caller of Application.launch, meaning that there won't be any uncaught exceptions.
24-05-2011
Verified that this is caused by RT-13602 which will be fixed shortly.
24-05-2011
I will look at this while looking at RT-13602 (although a separate fix might be needed)
18-05-2011
Note that this won't be fixed in the first beta, but in a subsequent update. Also, if you can attach a test program that will be helpful.
18-05-2011
I'm in the process of making sure that exceptions are thrown back to the application when an error occurs. I'll look into this at the same time.
18-05-2011