Java Reference
In-Depth Information
Listing 6.3. Using @ApplicationException to roll back CMTs
The first change from listing 6.1 you'll notice is the fact that the try-catch block has
been removed and replaced by a throws clause in the method declaration . But it's a
good idea for you to gracefully handle the application exceptions in the client and generate
the appropriate error messages. The various nested method invocations still throw two ex-
ceptions listed in the throws clause . The most important thing to note, however, is the
two @ApplicationException annotations on the exception classes. The @Applic-
ationException annotation
identifies a Java checked or unchecked exception as
an application exception .
An application exception is an exception that a client of an EJB is expected to handle.
When thrown, such exceptions are passed directly to the method invoker. By default,
all checked exceptions except for java.rmi .RemoteException are assumed to
be application exceptions. All exceptions that inherit from either
java.rmi.RemoveException or java.lang.RuntimeException (un-
checked) are assumed to be system exceptions. In EJB, it's not assumed that the client ex-
pects system exceptions. When encountered, such exceptions aren't passed to the client but
are wrapped in a javax.ejb.EJBException instead.
In listing 6.3 , the @ApplicationException annotation on CreditPro-
cessingException doesn't change the behavior of the exception—the exception is
passed up to the client. But the application exception annotation
changes the behavior
Search WWH ::

Custom Search