How exactly Application Exception is shown to the User in case of EJB

[Ravi Kiran Va]

Hi

Please let me know what is shown to the user when a Application Exception is thrown from a EJB Method ??

In case of UncheckedException it is wrapped as an RemoteException , but what in case of Application Exception ??


Please share your ideas .

Thanks .

[ramprasad madathil]

Application exceptions are propogated as is to the client. So if your business method throws an InsufficientFundsException and the exception is actually thrown at runtime, the client to that ejb call receives an InsufficientFundsException.

ram.

[Ravi Kiran Va]

Thank you very much ,

I posted this query , because i read that when a CheckedException occurs , it is wrapped into EJBException and in case of Unchecked it will be wrapped into RemoteExceptions .

can you please clarify this thing for me .

Thanks in advance .

[ramprasad madathil]

You are confused between Application and SystemExceptions versus Checked and RuntimeExceptions

The first is an ejb concept and while there are rules governing some aspects of it, it is upto your design to consider an exception as an application exception or system exception. There is nothing (except common sense) which prevents you from potraying the same exception (be it Runtime or Checked) both ways. There is no set of Exception classes which fall into one category or other.

On the other hand Checked and RuntimeExceptions is a java thing and there are strict hirearchial rules which designates an exception as belonging to one category.

An ApplicationException is one that the client has a chance to recover from and is therefore propagated as is back to the client. Though it is mostly a CheckedException defined in the throws clause, it is also possible (according to the ejb spec Sec 14.2.1) for it to be a RuntimeException. The only rule is that it cannot subclass RemoteException

A SystemException too can be a RuntimeException or a CheckedException. RuntimeExceptions should simply be propagated to the container. If an operation results in a CheckedException that the client cannot recover from (SQLException, JNDI Exceptions etc), it should be wrapped in an EJBException and thrown to the container.

Note the spec (sec 14.2.2) specifically states that this is suggested action and not mandated simply because there is no way to mandate it. For example if you chose to specify SQLException as an ApplicationException by defining it in the throws clause, it would be treated as such (presented back to the client without wrapping).

In short, the wrapping of CheckedExceptions and rethrowing it as an EJBException (thereby forcing it to be treated as a SystemException) is intentional design and not mandated by the spec or automatically achieved through the container.

ram.