On Tue, 21 Jul 2026 20:55:39 GMT, Andy Goryachev <[email protected]> wrote:
> I think what you listed in the first code block is good, as it always unlocks > even if an exception is thrown (and if not, all is well). Yes, but as said, there can't be any exceptions thrown, barring real bugs. We shouldn't catch bugs under any circumstances, unless they come from user code. The user code is, as shown in the above comment, accounted for already, so any exception that is now thrown still from that code would be a bug -- if there is indeed a bug (let's say in `ArrayManager`), then the list not being unlocked is probably the least of your worries... > The second question about eating (I mean, forwarding) the exception coming > from a listener and then continue calling other listeners, if I understand > you correctly, is a different issue. It might be a better approach, but I > don't know the implications. It was not a question, it was showing you that no exception can be thrown in that code because all code is FX code, and when where we're calling user code, we catch exceptions. > I noticed that javafx feels more brittle when something breaks wrt Swing. In > Swing the program typically continues maybe with some broken components, but > in javafx the whole layout is gone, and often reloading the pane does not > help (like in the monkey tester, when switching to a different page and back > re-creates the page). You should really investigate such exceptions and fix their cause. FX itself should never throw exceptions that could cause layout to break (barring resource issues or real bugs; so layout breaking in the course of FX development could happen if there was a bug). No reasonable user code should be able to break layout (I can always break layout by making an infinite loop, or by running down resources, or by throwing an Error, or calling `System.exit(0)`). > Also, what if it's not an `Exception` but an `Error` ? Do we want to catch > Throwable and forward everything to the `uncaughtExceptionHandler`? Errors are generally fatal. Under very specific circumstances you may decide to catch a specific error, but that should be specific in a narrow piece of code. For example, the user points a URL to an image, that turns out to be too large; the image load code could decide to catch `OutOfMemoryError` rather than crashing when it tries to allocates a huge data structure -- this is a reasonably safe pattern because there likely will be tons of memory usable still if a huge allocation fails. Another use case is when doing dynamic loading of code. You may want to guard such code with a catch block for `NoClassDefFoundError`, so you stop the load attempt and just log an issue. > I often do in my apps, but the next question is what do we do if the app > wants to catch the exceptions instead of using the `uncaughtExceptionHandler`? The user can set this handler, so I don't see a problem here. They can handle it any way they want, but we can't allow it be thrown as listener calls are often triggered in the middle of important subsystems (like CSS or layout), and they must be able to complete normally. Even if we did program this defensively, and use try/finally throughout the code, the exception would still need to be logged instead of completely bubbled up because otherwise the FX thread would be terminated. So user listeners should never throw exceptions. The guards we provide are a courtesy, to stop the entire FX application from breaking. If you want to do any custom handling, then catch those exceptions in your listeners. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-5039707367
