Hi guys, we had the same discussion a while ago when I added some code to swallow all exceptions that occur in event handlers. But (I think it was Alex) finally convinced me that event handlers should be capable throw exceptions which result in aborting the transaction. There are several use cases for such an behavior like strict requirements/obligations regarding audit data. In a real-world environment storing audit data in a reliable fashion is an absolute MUST. So in case of a data bases error, network fragmentation, harddisk crash etc, the event listener must be able to interrupt the actual execution because the execution can not be completed in the intended way (i.e. having all events in an audit trail can not be guaranteed anymore). Another use case would be "process repair". In case you have received a certain sequence of events you may figure out that the process instance does not behave in the intended way. In such a case you may want to either "repair" variable values or may want to fail the process instance.
I believe these are convincing points, therefore I suggest to either put the responsibility to catch runtime exceptions to the event handler developer or to introduce a dedicated exception for the explicitly reporting/wrapping an error and swallowing all runtime exceptions in Ode. But in general I agree that Ode should deal with such an exception in a meaningful manner, i.e. it should create a BPEL fault which then either bubbles back to the client or even could be caught by a BPEL faultHandler. Cheers, Tammo On Fri, Apr 4, 2008 at 10:08 PM, Thilina Gunarathne <[EMAIL PROTECTED]> wrote: > Hi Matthieu, > I completely agree with you that ODE should not fail due to a silly > mistake in an event handler. > > The next thing is if ODE fails like that in any case it's nice if it > notifies the waiting client (if there are any) about that... -- Tammo van Lessen - [EMAIL PROTECTED] - http://www.taval.de
