• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 201
  • Last Modified:

patterns for error handling in Java application...

Hi,

I am working on a web based application which has the following layers. The application conforms to MVC architecture and uses struts
1) JSP, tag handlers
2) Controller (struts)
3) Business tier
4) dB tier (JDO and/or JRF)

We are planning to use apache's Log4j for logging errors to log files. Log4j provides certain methods for logging errors depending upon the error severity. These methods are error(), warn(), debug() and fatal().

However, I intend to control the places where the errors should be logged to the log file. Only one tier should write/log to the log file. The most correct choice seems to be the business tier. The business tier is responsible for translating exceptions from the business tier into application specific exceptions and giving it to the controller layer. It also creates an error message for the user (which will be shown to the user on a error page for example).
The business tier will also log the error/exception to the log file. However, it needs to decide the severity of the error before calling the appropriate Log4j method. In order to do this, it will need some kind of a switch block.

I was wondering if there is a better way of logging errors and propagating exceptions given a multi-tiered application.

Kindly suggest an approach to effective exception and error handling (which involves logging as well).

Thanks
Shayad

0
shayad
Asked:
shayad
1 Solution
 
NeutronCommented:
Hi Shayrad :-)

One (out of many) possible solutions:

Independent of the tier where an exception is thrown, the implementor knows the best how fatal is the exception that was thrown.

You can have a base class for exceptions in your system, which is constructed not only with a message but with "fatality-level" id.
From this base class you can subclass various families of exceptions, so my suggestion is that system-wide you catch all "foreign" exceptions and convert/throw them as your own exceptions.

In the tier where you want the logging to be perfrmed you can then just "blindly" invoke the getter method for the level-id on the exception which reached that tier.

-

The other way to look at things, you could meddle with proxy-classes (reflection) and decide there what you log and what not. This is the harder way to do it so I won't go into details.

-

A finer version of the prevoius option is to make the smallest use of aspectj (www.aspectj.org) by making pointcuts through some families of classes and perform modular logging of exceptions thrown at locations that don't fit module bounds.

Good luck,
    </ntr> :)
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now