Throwing exceptions from entity bean lifecycle methods

[Simon]

Hi,

I have a @PreRemove method in an entity bean which frees some resources.
What is the preferred way to signal exceptions occurring in this method?
If an exception occurs, I would like to have the entire remove operation
rolled back.

I have tried to throw a regular exception, which, e.g., Glassfish does
not like. Apparently, it catches it and then tries to cast it to Error,
which certainly fails. This results in an extremely obscure log message
(a ClassCastException to Error), and the original exception is lost and
not logged anywhere. Am I supposed to throw Errors? Maybe RuntimeExceptions?

Any help is appreciated.
Cheers,
Simon

 

[Arne Vajhøj]

I have a @PreRemove method in an entity bean which frees some resources.
What is the preferred way to signal exceptions occurring in this method?
If an exception occurs, I would like to have the entire remove operation
rolled back.

I have tried to throw a regular exception, which, e.g., Glassfish does
not like. Apparently, it catches it and then tries to cast it to Error,
which certainly fails. This results in an extremely obscure log message
(a ClassCastException to Error), and the original exception is lost and
not logged anywhere. Am I supposed to throw Errors? Maybe
RuntimeExceptions?

Traditionally EJB's throw EJBException to signal rollback.

But don't know if @PreRemove methods are special.

Arne

 

[Arved Sandstrom]

Hi,

I have a @PreRemove method in an entity bean which frees some resources.
What is the preferred way to signal exceptions occurring in this method?
If an exception occurs, I would like to have the entire remove operation
rolled back.

I have tried to throw a regular exception, which, e.g., Glassfish does
not like. Apparently, it catches it and then tries to cast it to Error,
which certainly fails. This results in an extremely obscure log message
(a ClassCastException to Error), and the original exception is lost and
not logged anywhere. Am I supposed to throw Errors? Maybe
RuntimeExceptions?

Any help is appreciated.
Cheers,
Simon

According to the EJB3 persistence spec an entity lifecycle callback
method can throw an unchecked/runtime exception (Section 3.5). If a
runtime exception happens inside a transaction then the transaction will
be rolled back.

Arne mentioned EJBException: this extends from RuntimeException. This is
a decent choice. If you wish, use the EJBException ctor that embeds
another exception - this can be retrieved later using the
"getCausedByException" method on the EJBException instance.

Note: the example used in the persistence spec is terrible. After the
spec authors say (in several places) that entity lifecycle callback
methods are unchecked/runtime exceptions (Section 3.5, 3.5.6), they go
ahead in one code snippet and throw an AccountException in an example
@PrePersist method...with no definition of AccountException. You're
forced to assume that AccountException extends RuntimeException but if
you're inclined to focus on code snippets you may have missed that info
in the text, and get into difficulties.

I'm not sure what you mean by throwing a regular exception. The entity
lifecycle callback methods must have signature "int <METHOD>() {}".
There is no throws clause; you can't throw your own checked
"application" exceptions. So you must have had an unchecked exception,
which is OK. Perhaps you can clarify.

AHS

 

[Simon]

Thank you, Arved, that was very helpful for me. I should have looked
into the Spec earlier. I was looking for this information in tutorials,
which did not cover exceptions.

Note: the example used in the persistence spec is terrible. After the
spec authors say (in several places) that entity lifecycle callback
methods are unchecked/runtime exceptions (Section 3.5, 3.5.6), they go
ahead in one code snippet and throw an AccountException in an example
@PrePersist method...with no definition of AccountException. You're
forced to assume that AccountException extends RuntimeException but if
you're inclined to focus on code snippets you may have missed that info
in the text, and get into difficulties.

Agreed. But since @PrePersist method (validateCreate()) does not have a
throws clause it must be an unchecked exception.

I'm not sure what you mean by throwing a regular exception. The entity
lifecycle callback methods must have signature "int <METHOD>() {}".

^^^
Is that a typo or am I missing something? In section 3.5.1 it reads void
METHOD(), and the examples are also void.

There is no throws clause; you can't throw your own checked
"application" exceptions. So you must have had an unchecked exception,
which is OK. Perhaps you can clarify.

Yes, by "regular exception", I was, somehow obscurely, referring to
non-RuntimeExceptions, or rather, checked exceptions.

Cheers,
Simon

 

[Arved Sandstrom]

Thank you, Arved, that was very helpful for me. I should have looked
into the Spec earlier. I was looking for this information in tutorials,
which did not cover exceptions.

All the specs related to J2EE are quite well-written. Tutorials can be
incomplete or dangerous - a number of them which cover exceptions in
entity lifecycle callbacks are misleading or wrong.

Agreed. But since @PrePersist method (validateCreate()) does not have a
throws clause it must be an unchecked exception.

^^^
Is that a typo or am I missing something? In section 3.5.1 it reads void
METHOD(), and the examples are also void.

My typo.

[ SNIP ]

AHS