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. JEE makes the separation between two cases: 1. The app communicating an exception back to the client. 2. The container deems the app not reliable enough, rolls back the transaction, discards the bean, etc. We have the same behavior in BPEL. The process can communicate an error back to the client, using reply. Otherwise, the container has to deem the process unreliable, roll back the transaction, discard the process, etc. That simplifies development: 1. Catch exceptions you can handle and handle them. 2. Forward BPEL faults to the process when you have a consistent state and the process can decide what to do. 3. Fail in all other cases. Assaf > > > > > > 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. >
