On Mon, Apr 7, 2008 at 10:43 AM, Alexis Midon <[EMAIL PROTECTED]> wrote:

> Regarding #2 and #3: The special exception I mentioned was supposed to be
> a
> > solution for #2. My idea was to add a checked exception that indicates
> that
> > Ode shall rollback the transaction and should throw a BPEL fault while
> > unchecked exceptions are simply swallowed (logged but ignored).
>
>
> don't you think the ShouldRollBackException you suggest could be
> unchecked,
> something similar to what JEE
> describes<http://java.sun.com/javaee/5/docs/tutorial/doc/bnbpj.html>
> .
> No changes to the public API are necessary, only a new contract between
> handlers and ODE server.
>
>
I'm not a big fan of this part of JEE (like many other parts actually) but
I'll go with the flow, a specific exception to signify failure sounds good
enough. I'm anticipating troubles with this little interface though, as soon
as we'll want to support more advanced use cases (as Tammo described). We'll
have to spend time thinking of those carefully at some point.

Cheers,
Matthieu


>
> > I tend to prefer this over adding a call back method as this implies
> more
> > changes to the interface (need for an abstract class) and is IMHO not
> that
> > intuitive to use.
> >
>
> Agree with Alex. A failOnError() method sounds too monolithic/binary and
> an
> exception itself can convey this information in a more flexible way.
>

Reply via email to