• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

@AroundInvoke interceptor methods and system exception handling

 
Himai Minh
Ranch Hand
Posts: 1359
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On p. 61 of Frit's notes, in the table, business interceptor (@AroundInvoke) allows application exception handling. But the system exception events field is empty.
Does it mean @AroundInvoke method won't throw any system exception?

But in the JSR 318, p.385, it says

Table 15 specifies how the container must handle the exceptions thrown by the methods of the business interface... including the exception thrown by business method interceptor...

And table 15 shows that the system exceptions are logged, marked for transaction by the container, container discards the instance if not singleton and throws EJBTransactionRollbackException to client.


 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2531
112
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does it mean @AroundInvoke method won't throw any system exception?

No, all interceptor methods can throw a runtime exception (according to interceptors v1.1. specs), however I didn't find the way the container should handle those. I expected that to be specified in the interceptors specs.

But you found them in a small sentence above table 15 (and table 16 as a matter of fact) of the EJB specs!!

Great, I will update my notes, thanks, that deserves a cow!

 
Himai Minh
Ranch Hand
Posts: 1359
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Frits. Thanks for the reply.
Here are the quotes from interceptor 1.1 specification:

Around - invoke interceptor methods may throw any exceptions that are allowed in the throws clause of the target class method on which they are interposing.



Around-timeout interceptor methods may throw any exceptions that are allowed in the throws clause of the timeout method on which they are interposing.



Life cycle callback interceptor methods may throw runtime exceptions, but not checked exceptions.

(Actually, life cycle callback interceptor methods may throw system exceptions, as specified in JSR 318.)

There may be a clue about how the exception thrown by these interceptors to be handled:
In interceptor 1.1 specification:

InvocationContext.proceed() will throw the same exception as any thrown by the associated target method.....
Exceptions and initialization and/or cleanup operations should typically be handled in try/catch/finally blocks around the proceed method.


It seems to me that the developer should be responsible for the exception handling for timeout callback and lifecycle callback interceptors. The container is not responsible to log and rollback any transaction in case of a system exception thrown by timeout callback and life cycle callback interceptor. However, any system exception thrown by around invoke interceptors will be logged and rollbacked by the container, according to JSR 318.


 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2531
112
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It seems to me that the developer should be responsible for the exception handling for timeout callback and lifecycle callback interceptors

I agree when it comes to Checked Exceptions. However System Exceptions shouldn't be handled there.

The container is not responsible to log and rollback any transaction in case of a system exception thrown by timeout callback and life cycle callback interceptor.

I think this is specified in table 23 and 19 on pages 394 and 391 respectively. In other words JSR 318 specifies system exception handling of all types of interceptors.
 
Himai Minh
Ranch Hand
Posts: 1359
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Frits. Thanks for your reply.
Combining JSR 318 and Interceptor 1.1,
if the lifecycle callback interceptor method or timeout interceptor method has a try/catch block to handle any application or system exception, the container does not need to handle it.
But if these interceptors do not have the try/catch blocks to handle the exceptions, the container will log the exception, rollback the transaction, discard the instance if applicable (table 19 and 23 of JSR 318).

 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2531
112
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Updated and uploaded to the ScbcdLinks.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic