Exception Handling in a Java Web Application

Question

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

Kiakiah

Answer 1

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.

Pepper

Thank you for the response. Regarding #3, how can we catch an unhandled exception in Filter, if the filter listens on the error page? – Kiakiah

It's stored as request attribute with the name exception. On the other hand, you can also handle the exception and forward to the error page in the filter yourself by just placing chain.doFilter(request, response) inside a try/catch block. – Pepper

Answer 2

If you can't recover from an exception, then you should let it flow out of your code (often by making it unchecked, or wrapping it in an unchecked exception). If they remain checked, you have to cater for them at each level of your code, and consequently at every abstraction layer. SQLExceptions would normally fall into this category (you'll have to wrap them since they're checked).

For these exceptions, I normally log at the highest level, but present a page to the users simply detailing that something has gone wrong. Normally my users aren't interested in stack traces. But I usually offer them a page to let them describe what they were doing at the time, and the logged exception ties back to this submission via a unique id (recorded in the form and in the log file with the exception). That allows me to tie back users' actions to the resulting exception.

The above assumes that you can't recover from SQLExceptions, and if the database is down, then you can't do something meaningful. There are exceptions to this, of course. You may find that you're talking to multiple systems, and one being down doesn't mean you can't continue in some fashion (e.g. the Amazon home page reportedly relies on 100 services, and needs to run regardless of some of these being down).

I would expect declared exceptions to be at the same level of abstraction as the interface/methods defining them. e.g. a TradeStore would be declared to throw a TradeException, not a SQLException (since methods of storing a trade are an implementation of TradeStore - you could store in a relational db, a JavaSpace etc.).

Moskow

Thank you Brian. +1 for the TradeStore example. – Kiakiah

Answer 3

As a warning, when displaying lower level error messages to users, make sure they're sanitized of system information. This is an area where many security exploits originate. Log them with full information, but only display a more general error message to the user.

Toothsome