What level to use for exception stack trace logging in Java?

I'm looking for best practices document (or your opinions) on how to effectively log exceptions and their stack traces. Of course, assuming one of popular logging frameworkks such as Log4J, SLF4J, java.util.logging, etc.

I'm particularly interested in your opinion about on what level stack traces should be logged.

I heard few contradicting each other opinions such as:

• stack traces should be logged only on DEBUG level while ERROR level should contain only "human readable" error message
• stack traces should be logged on ERROR level in order to give to the operator maximum amount of information required to find root cause of an exception

I have found couple o开发者_开发知识库f interesting articles however none of them touches this particular subject:

• http://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html
• http://today.java.net/pub/a/today/2003/12/04/exceptions.html

which probably means that authors of these articles had same concerns as I do :-)

I'd be really interested in your view on this subject.

Stack trace is the most valuable piece of information you get when troubleshooting. I would never risk logging it on DEBUG level since it might be disabled. And I almost never want to suppress stack traces.

Also note that:

log.error("Houston, we have a problem", ex);

will print the human readable message in line marked as ERROR, while the stack trace is following that line. If you want your errors to be only human readable, just do grep ERROR.

I'm not sure about best-practice advice for this, but in the end, for me it boils down to this: Exceptions should only be visible in exceptional circumstances. The concept of exception was invented to give developers a chance to handle errors internally.

In reality, most code I see doesn't even try to handle them, instead dumping them to the log, sysout, (or worst case of all) into dialog boxes. I know, that for a developer it is important in some cases to get the full stacetrace. But not nearly in all of them. Creating your own exception framework (which is definitely a best practice) might already be enough to figure out the context of an exception simply by classname.

So I would advise to do the following:

1. Create your own exception framework
2. Include specific error codes in the message, for your reference
3. Log the exception message on ERROR
4. Log the stacktrace on DEBUG
5. NEVER EVER display the user either of these. Instead show a useful message. Maybe include a way to report the error (with stacktrace) with minimal fuzz.

Note: If you are writing an internal "enterprise" software, forget everything I wrote. :-)

I think the stack trace should be logged at the appropriate place based on priority best practices. Depending on the nature of the exception and its place within your application, this may be one of many levels. Please see this related question: Commons Logging priority best practices