JDK-8095557 : Fix for RT-33633 breaks the ability for application developers to deal with exceptions properly
  • Type: Bug
  • Component: javafx
  • Sub-Component: application-lifecycle
  • Affected Version: 8u20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-04-21
  • Updated: 2015-06-12
  • Resolved: 2014-04-22
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.
JDK 8
8u20Fixed
Related Reports
Relates :  
JDK-8098064 - Exceptions by Invalidation- or ChangeListeners are not caught
Description
The fix for bug RT-33633 causes a regression of bug RT-15332.

I don't think you can consider catching and logging any exception in a listener notification as good error handling practice. It will cause many real bugs to go totally unnoticed.

In a core architecture like this it is impossible to know the effects of swallowing all exceptions and therefore unecessary to be worrying about notifying the rest of the listeners that are registered. While the FX app thread may not be about to die in these scenarios, as commented in RT-33633, the UncaughtExceptionHandler should still be called since the unexpected exception may render the whole UI corrupt or unstable. The UncaughtExceptionHandler is the only way for an applicaton developer to be notified of unexpected errors so he can notify the user that the application is potentially unstable.
Comments
Changeset (and post-commit review): http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/669f56bc38e9 Unit tests: ExpressionHelperTest#testExceptionHandledByThreadUncaughtHandlerInSingleInvalidation ExpressionHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleInvalidation ExpressionHelperTest#testExceptionHandledByThreadUncaughtHandlerInSingleChange ExpressionHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleChange ExpressionHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleChangeAndInvalidation ListListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInSingleInvalidation ListListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleInvalidation ListListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInSingleChange ListListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleChange ListListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleChangeAndInvalidation SetListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInSingleInvalidation SetListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleInvalidation SetListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInSingleChange SetListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleChange SetListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleChangeAndInvalidation MapListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInSingleInvalidation MapListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleInvalidation MapListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInSingleChange MapListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleChange MapListenerHelperTest#testExceptionHandledByThreadUncaughtHandlerInMultipleChangeAndInvalidation
22-04-2014
I didn't know we are already using UncaughtExceptionHandler in FX. Since this is used for all (other) app thread exceptions, I guess we can also use it with listeners.
22-04-2014
Yikes! Please consider reverting the exception swallowing behaviour introduced in RT-33633. I can see how it might seem more robust to allow all remaining listeners to continue running normally even after one listener throws an uncaught exception, but this behaviour is effectively a form of the "error hidiing" anti-pattern (sometimes also known as the "sweep it under the rug" anti-pattern.) Most Java developers rely on uncaught exceptions as a way to detect coding errors. But if JavaFX silently swallows a subset of these exceptions, then only way we'll ever discover our errors is if we (or our users) are running our application while paying attention to an open console window in the background (assuming JavaFX logs the exceptions before swallowing them.) That's going to make maintenance and development needlessly harder.
21-04-2014
Assign to Martin to evaluate the impact and whether it needs to be fixed.
21-04-2014