Best Practice for EJB Remote Exceptions

[Douglas Kent]

Should the bean class catch all application-level exceptions, deal with them and re-throw EJBException? And thus declare no exceptions in its methods? That way, the remote interface only has to declare "throws RemoteException".

By way of explanation, I am getting an error in the Sun One deploytool verifier that complains thusly:

Error: method [ TrRequest ] does not throw valid application exceptions in Remote/Local interface

thanks!

[Tim Holloway]

I wouldn't recommend it. My experience is that it's best to make your exceptions be as specific as possible. It helps document what particular things are likely to go wrong, and it allows you to use multiple catch clauses instead of a big ugly single clause with instanceof tests. And that's especially useful since you can capture only the exceptions you want to handle and percolate the others out to somewhere more appropriate.

I even go so far as to provide private inner-class for exceptions specific to objects. Although I can't trap them by name, having a unique exception name adds to the information displayed on the stack trace/debugger. I imagine some may object to that practice, though.

[Douglas Kent]

Thanks, Tim. My thought was to wrap all the application exceptions in the EJBException, which will be re-thrown to the client as a RemoteException, who can then interrogate the wrapped exception to determine what happened. Since the client calls only the stub, it seems that is a good way to go...