Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] Getting "default" feedback from the executor thread when an uncaught exception occurs

Hi Mario,
Because of quirk in how the java.util.concurrent.ScheduledThreadPoolExecutor is implemented, it's not easy to catch and log all exceptions that are thrown in the executor thread.  The best that we can do currently is enable this logging when assertions are enabled.  In the launch configuration for your PDE session add the "-ea" option to the VM arguments.  Internally this causes wrappers to be used for all runnables to the executor, and those wrappers catch and log the exceptions.

Hope this helps,

Mario Pierro wrote:



I would like to ask a question about exception handling in DSF Sequences (and, more generally, in asynchronous DSF operations).

What is the default exception handling policy that DSF uses? (We are using DSF release 1.0 maintenance.)


I am asking this because in our implementation it seems that a generic Exception thrown during the backend startup sequence can freeze the whole sequence without any visible feedback. This seems to happen only if the exception is unhandled by the sequence code, so it gets uncaught up to the sequence executor.


The only way to notice that an exception has occurred is to set an exception breakpoint: stepping through the exception return path shows that it gets to the and it is ignored there, with the executor only shifting to the next task – thus leaving the request monitor incomplete and freezing the sequence.


Does the DSF API provide a “last-resort” way of getting uncaught exceptions, at least to show that they have occurred?





_______________________________________________ dsdp-dd-dev mailing list dsdp-dd-dev@xxxxxxxxxxx

Back to the top