I need efficient logging infrastructure in my system (less code to maintain). I have logging utility that logs exceptions in two separate files (one with Java trace and other in plain text for End users). Is it a best practice to have some Exception be log aware and be "Self" log-able i.e., when an exception is created log the stack trace and message?

If you do this, make sure you do it at a low logging level (debug), otherwise your log files will fill up very rapidly with huges amounts of information.

Also, this will only log your custom exception classes, not exceptions thrown by other APIs (e.g. SQLExceptions).

Personally, I prefer to let unrecoverable exceptions rise up to some sort of central controller class, and log the error there. This only works if all the system invocations are passing through a single controller class, but this is often the case for web-apps (which is what I write).

But is this a best practice? Aren't we coupling two different functionalities? What if the developers start creating new exceptions but throw them to log? Is it being miss used or is it advantageous to use because of the stack trace and exception chaining?

Thanks
Ravi

Let me explain more...

try
{
 ... do something
}
catch(ExWithExceptionChain exToExtractStackTrace)
{
 new SomeExceptionsThatLog("LogMeText", exToExtractStackTrace);
}

We aren't throwing SomeExceptionsThatLog here, but just create new instance that facilitates logging.

In other places we may use it like below:
try
{
}
catch(SomeOtherException soe)
{
throw new SomeExceptionsThatLog(...,...);
}

Is this appropriate?

Is it not better...to use an utility class to achieve the logging functionality and use exception as exception?

Thanks
Ravi

Did somebody mention "Aspect Oriented Programming (AOP)"?
-Sanjay

Ravi, it sounds like you already have an answer to your own question.

You are correct, it is unusual to assume that the exceptions will log themselves, and this is not a typical way of implementing logging. The common practice is to use some logging utility, such as JDK 1.4 logging or Log4J.

There are lots of potential problems with self-logging exceptions:

1) Often the exception itself does not have enough meaningful information to create a good log entry.

2) Sometimes an exception is recoverable, and therefore should not be logged.

3) There is also the issue of existing exceptions, as I discussed above.

If you do write exceptions that log themselves (which I would not recommend) be sure to add a level of abstraction. Your functional code should not have a tight relationship to technical implementations (the specific logging api).

My suggestion: business logic and related exceptions should not be aware of the environment. Put your logging code into application specific code (like your web controller), not into (potentially) reusable business logic.

Kind regards,

Andreas Berg
Triona