On Sat, Aug 23, 2003 at 12:19:05PM -0700, Jeremy Boynes wrote: > Currently an invocation results in an InvocationResult which, at it > simplest, contains the return value from a method call. Exceptions from the > method call get thrown up the interceptor stack. > > I am proposing we change InvocationResult to be aware of the three possible > exit conditions from a method call: > * normal return > * declared Exception (method threw checked Exception) > * undeclared Exception (method threw RTE or Error) > > This would change the return phase of the interceptor stack so that > Exceptions from the invoked object would be in the InvocationResult rather > than being thrown from getNext().invoke(). This would allow us to easily > separate exceptions raised in user-land from exceptions thrown by the system > (container/interceptors). > > Is this a good idea or a bad idea?
What about when a container/interceptor itself throws an error, this still needs to reach the client as an ordinary RemoteException/EJBException. We returned exceptions rather than throwing them in OpenEJB at first, just as you're proposing. We eventually took it out simply because exceptions can still occur on the way back to the client. So you end up catching exceptions anyway, but now your code is split between try/catches and some if tests on the result object. Still works, but looks a little goofy. Actually, I don't see the need for an InvocationResult interface. Seems like it was added for just-in-case flexibility, but after years of existence it still isn't getting leveraged for anything. The RPCContainer interface of OpenEJB has been like this for years with no problems: Object invoke(<invocation data>) Exception We actually do wrap exceptions though. - If the bean throws a checked exception, we wrap it with a special exception type. When the client side get the exception, it pulls out the nested exception and throws it. - If the bean throws an unchecked exception, we wrap it in a different exception (InvalidateReferenceException). When the client get's one of those, the proxy is invalidated as the bean was garbage collected, the nested exception is then thrown which will be a RemoteException/EJBException/TransactionRolledbackException/etc. Same thing as you're thinking, but just done by wrapping the exception as a more specific invocation related exception rather than masking it as a return value. -David
