Because lifecycle methods are invoked by the container, there really is no sense in throwing application specific exceptions during the invocation of a lifecycle interceptor method. As such, lifecycle interceptor methods may not throw application exceptions, although they are allowed to throw RuntimeExceptions. If a runtime exception is thrown during an EJB3 lifecycle callback interceptor method, the interceptor chain unwinds, and the EJB instance is discarded. Of course, what else can you really do when a RuntimeException is thrown?
"Lifecycle callback interceptor methods may throw system runtime exceptions, but not application exceptions.
A runtime exception thrown by any lifecycle interceptor callback method causes the bean instance and its interceptors to be discarded after the interceptor chain unwinds. The lifecycle callback interceptor methods for a lifecycle event run in the same Java call stack as the lifecycle callback method on the bean class. InvocationContext.proceed() will throw the
same exception as any thrown by another lifecycle callback interceptor method or lifecycle callback method on the bean class unless an interceptor further down the Java call stack has caught it and thrown a different exception. A lifecycle callback interceptor method (other than a method on the bean call or its superclasses) may catch an exception thrown by another lifecycle callback interceptor method in the invocation chain, and clean up before returning. Exceptions and initialization and/or cleanup operations should typically be handled in try/catch/finally blocks around the proceed() method. The PreDestroy callbacks are not invoked when the bean and the interceptors are discarded as a result of such exceptions: the lifecycle callback interceptor methods in the chain should perform any necessary clean-up operations as the interceptor chain unwinds."
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment