Exception Handling in a Java Web Application

craftsman picture craftsman · Jan 30, 2010 · Viewed 11.1k times · Source

I am developing a medium size Java Web Application with Struts as MVC framework and simple JDBC at Data Access Layer. I have been searching for exception handling best practices in such an application. I have found several articles, some of them being contradictory, only making me more confused rather than making things clear and simple. Some say it is better to reuse existing exceptions instead of defining application specific exceptions, others present a huge hierarchy of application specific exceptions for every minor trouble that may occur in the system. Some say it is better not to handle exceptions at Data Access Layer and delegate them to the Service Layer, others say Data Access Layer exceptions should be caught locally since delegating them to Service Layer would violate the abstraction between the two layers. And so on.

I would highly appreciate if you let me know of links/names to articles/books that present solid solutions which have worked for you in such a scenario. The solution should clear at least the following points with justifications:

  1. Where the SQLExceptions be caught?
  2. Where exceptions should be logged?
  3. Should unchecked exceptions be logged?
  4. Should unchecked exceptions be caught at presentation layer, and should they be shown to the user?
  5. How checked exceptions be handled, which of them to be shown to the user and how?
  6. How should a global exception handler page be used?
  7. How should struts ActionErrors be used in this context?

Thanks

Answer

BalusC picture BalusC · Jan 30, 2010

1: Where the SQLExceptions be caught?

In DAO classes in data access layer. You can if necessary wrap it with a custom DAO exception. This DAO exception in turn needs to be handled further as checked exception.

2: Where exceptions should be logged?

At the moment when you're about to throw them or to pass through the messaging framework.

3: Should unchecked exceptions be logged?

They should certainly be logged. They should namely not occur in real world, because those are sign of a fault in the code logic (i.e. developer fault) which needs to be bugfixed asap. They should be thrown all the way up to the container and let the container handle them with an <error-page> in web.xml. To log (and eventually mail) them, use a Filter which listens on the error page.

4: Should unchecked exceptions be caught at presentation layer, and should they be shown to the user?

They should not occur at all.

5: How checked exceptions be handled, which of them to be shown to the user and how?

If they are result of errorneous user input (e.g. not a number, bad email, constraint violation, etc), show them in the same form to the user. Otherwise (e.g. DB down, DAO exception and so on) either throw it all the way up to the error page, or display the error with a message to try again later.

6: How should a global exception handler page be used?

At least in an user-friendly manner. Thus, in the same layout, with some introductory "sorry" and if necessary with some error details and an email address so that the user can contact for the case that.

7: How should struts ActionErrors be used in this context?

Show them in same form to the user.