File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Exception Handling in EJBs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Exception Handling in EJBs" Watch "Exception Handling in EJBs" New topic
Author

Exception Handling in EJBs

Peter Storch
Ranch Hand

Joined: Jun 12, 2003
Posts: 74
Due to preparation for the exam I refreshed the exception handling in EJBs and read the EJB2.0 specs.
The spec makes a different between application and system exceptions. It states that a Bean Provider should use application exceptions only for business type of errors (e.g. limit exceeded) and not for system level problems (e.g. jndi, sql, io ... exceptions).
Only system exceptions cause a rollback by the ejb container. BTW: this may break older code relying on all exceptions causing a rollback.
Now I'm a little bit confused about how the exception handling should be implemented in your beans properly.
Is it really the goal to catch all system like exceptions (SQLException, IOException, JMSException ...) and wrap them into your own Exception inherited from java.lang.RuntimeException or throw a javax.ejb.EJBException?
Im thinking about how to inform an ebj client of what happened and what can happen by using an ejb. The system exceptions are java.lang.RuntimeExceptions and therefor unchecked and not declared in the remote interfaces.
Is there a best practice of exception handling around? How are you implementing the exception handling in your beans?
And there is always the issue about logging and preserving the full stacktrace.
There have been some interesting discussions around about checked and unchecked exceptions.
http://www.theserverside.com/home/thread.jsp?thread_id=19192&article_count=114
http://www.mindview.net/Etc/Discussions/CheckedExceptions
Does this mean that SUN is turning to unchecked exceptions for technical exceptions? Are the checked exceptions of the lower level APIs (JMSException, SQLException, ...) a design mistake from the past?
Ok, this questions is not really relevant to the SCBCD (you just learn whats in the specs), but I belive we shouldn't lose the implementation out of sight.
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
we catch checked exceptions within our code and
1.log it,
2.mark the transaction for rollback using setRollbackOnly(),
3.Wrap it in a generic Application Exception we have defined for the application and re-throw it back to the client.
Since we use application exceptions they have to be declared in the throws clause. So the client knows about it. The client can extract the actual exception from the App exception.
We dont do anything with the runtime exceptions. They just propogate as it is to the container.
I guess even ejb spec recommends this. I think this is a commonly followed practice.
The web tier handles such exceptions and displays a decent error message to the client.
Peter Storch
Ranch Hand

Joined: Jun 12, 2003
Posts: 74
Originally posted by karthik Guru:

1.log it,
2.mark the transaction for rollback using setRollbackOnly(),
3.Wrap it in a generic Application Exception we have defined for the application and re-throw it back to the client.


That's similar to that how we handle exceptions, but the spec says somethin else:
Application Exceptions:
"Enterprise bean business methods use application exceptions to inform the client of abnormal application-
level conditions, such as unacceptable values of the input arguments to a business method. A client
can typically recover from an application exception. Application exceptions are not intended for reporting
system-level problems."
System Exceptions:
"Examples of such exceptions and errors are: failure to obtain a
database connection, JNDI exceptions, unexpected RemoteException from invocation of other
enterprise beans[31], unexpected RuntimeException, JVM errors, and so on."
and
"If the bean method performs an operation that results in a checked exception[32] that the bean
method cannot recover, the bean method should throw the javax.ejb.EJBException
that wraps the original exception."
(The EJBException is a subclass of RuntimeException and therefor unchecked.)

The last quote from the spec is what I'm curios about.
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
This discussion may help:
http://www.coderanch.com/t/157805/java-EJB-SCBCD/certification/EJB-Exception-Handling-cheat-sheet


SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Exception Handling in EJBs
 
Similar Threads
Exception or RuntimeException
EJB 101 Damnations
EJB VS JDO
are EJBs portable?
Question on EJB2.0 Local interface