Question

I’m trying to better understand exception handling and logging in a j2ee environment to refactor some legacy code (we use log4j for our logging mechanism). Most of our current code does something like the code below on the business tier, however, I’d like to switch over to unchecked exceptions and just ignore them unless it makes sense to handle them somewhere:

try {
    doSomething();
} catch (MyException e) {
    log.error("Exception:", e);
    throw e;
}

After the exception is thrown in the business tier, it is then propagated up to the presentation tier, which again catches the exception and usually wraps it in a PortletException or ServletException and throws it again. Then, it is handled by a Spring handler which shows a ‘friendly’ message to the user. I’d ultimately like to only handle exceptions for which we want to show a specific error message, and just ignore everything else.

Questions:

1. Is it necessary to log exceptions in the business tier? If not, do
   I need to log exceptions at all (especially unchecked ones)?
2. What happens to uncaught exceptions that are not logged using log4j?
   (If they’re still printed in the console, what’s the purpose of
   log4j?)

I am confused as to how the process works…

Thanks.

EDIT: If an exception occurs in an outside library (Spring, Hibernate, etc), is it assumed that these exceptions will be printed out using whatever logging mechanism is being used? In that case, I guess that I would only need to log the exceptions that my code throws… or am I way off base here?

Answer 1

Before proceeding any further, please take a careful look at:

The following are some of the generally accepted principles of
exception handling:

1. If you can’t handle an exception, don’t catch it.
2. If you catch an exception, don’t swallow it.
3. Catch an exception as close as possible to its source.
4. Log an exception where you catch it, unless you plan to rethrow it.
5. Structure your methods according to how fine-grained your exception handling must be.
6. Use as many typed exceptions as you need, particularly for application exceptions.

Point 1 is obviously in conflict with Point 3. The practical solution is a trade-off >?between how close to the source you catch an exception and how far you let it fall before you’ve completely lost the intent or content of the original exception.

IBM DeveloperWorks: EJB best practices

It is usually advised that you use checked exceptions for application exceptions at the business tier. I prefer to follow the business interface pattern to decouple the business tier from the user interface and web tier. This will allow me to think of your business tier as a service layer library and callers might want to handle different situations differently when calling this layer. That is one reason you might want to include checked exceptions, since you can react differently to different exceptions. Furthermore, including checked exceptions will usually help the caller code to be better aware of what different situations might arise from invoking some functionality. It could be worth it to take a look at the business delegate pattern and how it might help you with exception handling. In short, the business delegate pattern allows you to create a very thin layer between the business layer and the web layer where you can do things like exception handling.

No matter how you go about doing this, make sure that you understand the implication of adding an application exception to your Java EE application. You may need to investigate how it interacts with your transaction management logic, specifically when it comes to transaction rollbacks. In my line of work, I had to add an @ApplicationException(rollback=false) to forbid the transaction manager from rolling back my transaction when an exception is thrown and propagated upwards.

You may be able to tell I was working with EJB, but the concepts are probably very applicable to your design as well.

So back to your questions:

Is it necessary to log exceptions in the business tier?

It is not necessary if you plan to log it later on. You better devise a logging strategy at a high level and log all caught exceptions there.

If not, do I need to log exceptions at all (especially unchecked
ones)?

I think that you should log exceptions because that will help you debug any issues later on. The user is usually not savvy enough to capture any output that might be produced if the exception propagates and gets printed on his/her screen without you handling it.

What happens to uncaught exceptions that are not logged using log4j?
(If they’re still printed in the console, what’s the purpose of
log4j?)

I think it will eventually be caught by the web container and be printed out to the console. If an exception propagates upwards and reaches the web container exception handling safety nets, your exception is out of control. It is usually a sign of bad design. It is best if you keep your exceptions under control. Why wonder how a container will react to an uncaught exception? Also how beneficial will that exception be to the user? I think the information presented from uncaught exceptions are almost useless, as they are so far from the source of the error, that they become irrelevant and hard to work with when debugging.