Transactions and security - EJB 3 in Action - page 235

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 .

Note

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