Stephan Gruschke wrote:
>
> Hello Rickard,
>
> Monday, July 24, 2000, 3:26:57 PM, you wrote:
>
> R�> Hi!
>
> R�> Stephan Gruschke wrote:
> >> Oh, yeap. The problem is that if an exception occurs in an bmp entity
> >> bean, an InvocationTargetException is thrown. The exception is an
> >> wrapper for the real exception thrown by the bean. What should be the
> >> preferred way: Wrap the returned bean exception in an create exception
> >> or return the real exception?
>
> R�> As it says in the EJB spec is the preferred way ;-) (i.e. go look it up)
> Well the ejb spec states that the original exception should be thrown.
> That's clear.
Almost. The exact behavior is specified in EJB spec. section 12.3.1.
If the container just started a transaction on the home.create() call
(RequiresNew attribute, for example), it should try to commit the
transaction before throwing the application exception (unless
setRollbackOnly() was called in which case the transaction must be
rolled back).
> But the problem is *who* should throw the original exception?
> BMPPersistenceManager or some module higher responsible for the
> invocation of the client?
>
> The idea was sending back the Create- or the InvocationTargetException
> and letting some higher module (for example EntityContainer?) the
> responsibility to send the real exception. This would decrease the
> amount of different exception types thrown inside of an entity bean call
> and would result in some easier handling of different exceptions,
> wouldn't it?
Unwrapping the InvocationTargetException on a higher level might
solve similar problems elsewhere, but that is probably answered
better by someone more familiar with the code.
> Another point would be distinguishing between exception thrown by the
> bean and by the container. An bean could throw an InvocationTargetException
> and it would be impossible for high-level modules to determine if the
> exception was thrown by the container or the bean. If the bean
> exception would be wrapped by some well defined exceptions inside
> the container the interface to other modules would be more precise.
That shouldn't be a problem: The java.lang.reflect.Method.invoke()
method just wraps any Throwable thrown by the invoked method, so if
the bean throws an InvocationTargetException we get an
InvocationTargetException wrapped in another InvocationTargetException.
Best Regards,
Ole Husgaard
