1 Reply Latest reply on Jul 8, 2005 8:11 AM by jaikiran pai

    cactus not catching application exception but wrap it in Nes

    Ho-Ki Au Newbie

      i would like to write cactus tests for a stateless session bean. some
      methods on the ejb throw application-specific exceptions. in some of
      my test cases, i would like to catch the application-specific exception
      and pass to make sure that case is correct. however, when the
      application-specific exception is thrown, it is wrapped in a
      org.jboss.util.NestedError. the nested error is the exception i want
      to catch. why does jboss do that? can i configure jboss so that the
      application-specific exception is thrown instead?

        • 1. Re: cactus not catching application exception but wrap it in
          jaikiran pai Master

          Following is a brief description about how EJB container handles exception. I found this on some site.

          How the EJB container handles exceptions:

          The EJB container intercepts every method call on the EJB component. As a result, every exception that results in a method call is also intercepted by the EJB container. The EJB specification deals only with handling two types of exception: application exceptions and system exceptions.

          An application exception is defined by the EJB spec as any exception declared on the method signatures in the remote interface (other than RemoteException). An application exception is a special scenario in the business workflow. When this type of exception is thrown, the client is given a recovery option, usually one that entails processing the request in a different way. This does not, however, mean that any unchecked exception declared in the throws clause of a remote-interface method would be treated as an application exception. The spec states clearly that application exceptions should not extend RuntimeException or its subclasses.

          When an application exception occurs, the EJB container doesn't roll back the transaction unless it is asked to do so explicitly, with a call to the setRollbackOnly() method on the associated EJBContext object. In fact, application exceptions are guaranteed to be delivered to the client as is: the EJB container does not wrap or massage the exception in any way.

          A system exception is defined as either a checked exception or an unchecked exception, from which an EJB method cannot recover. When the EJB container intercepts an unchecked exception, it rolls back the transaction and does any necessary cleanup. Then the container wraps the unchecked exception in a RemoteException and throws it to the client. Thus the EJB container presents all unchecked system exceptions to the client as RemoteExceptions (or as a subclass thereof, such as TransactionRolledbackException).

          In the case of a checked exception, the container does not automatically perform the housekeeping described above. To use the EJB container's internal housekeeping, you will have to have your checked exceptions thrown as unchecked exceptions. Whenever a checked system exception (such as a NamingException) occurs, you should throw javax.ejb.EJBException, or a subclass thereof, by wrapping the original exception. Because EJBException itself is an unchecked exception, there is no need to declare it in the throws clause of the method. The EJB container catches the EJBException or its subclass, wraps it in a RemoteException, and throws the RemoteException to the client.