search

JPro-one / JPro

The right place to report about bugs or suggest improvements for JPro.
https://www.jpro.one
9 stars 4 forks source link

JPro and uncaught exceptions - Best practices #159

Open guirak opened 1 year ago

guirak commented 1 year ago

Hi Florian,

With JPRO, what is the best practice to manage uncaught exception and display something in the good session ?

setUncaughtExceptionHandler seems to be not usable as if I declare some processing with this, the error message or another feedback for the user will be displayed in the session that override the setUncaughtExceptionHandler in last.

What are the best practice ?

A way found is to register a runnable with jpro instance value as key.

Is it good to do this ? Or there is something else possible with JPRO to manage exceptions ?

Thank you

guirak commented 1 year ago

The idea that I said will not work as when the exception occurs, we have only parameters "final Thread thread, final Throwable throwable" and we can't know with them the session for which the exception occurs.

Is there some TLS variable that store something like WebApi, instance id or the JProApplication when a thread is triggered from user action or some call to Platform -> runLater ?

FlorianKirmaier commented 1 year ago

Sorry for not getting back to you sooner - what we could do is, provide the information of which user/Scene we are currently processing the input. Generally, knowing the source is probably not possible - but in some limited way, it should work.

We could provide the Scene/Stage/WebAPI of the instance in which input is processed. But if we call run later, this information would be lost - but it would work well for event processing.

guirak commented 1 year ago

Hi Florian, Thank you for your return. My processing on input switches often of thread before giving the answer to the user. So it will be difficult to have something stable in this way. For the moment I have put in standby this problem and don't notify in the UI when an uncaugth exception occurs... As I am programming in a reactive way and try to generalize this maybe I would be able to found a solution wrapping the reactive publishers.

FlorianKirmaier commented 1 year ago

I think it's a pretty tricky problem. When you compare it to "HTML-Webframeworks" they have the identical problem. Unreported exceptions are not associated with a user, therefore, can't be handled properly.

But for the user input itself we should be able to improve the situation.

For async code - usually, the Futures should have some sort of "onFailure" code at the end - which should still be associated with the corresponding user.