When to log a stacktrace for a caught exception

I recently asked whether to report the getMessage() text of a caught exception. Rather surprisingly, most answers misunderstood my question and thought I was asking whether to report the stack-trace for a caught exception, suggesting that doing so is considered the norm. So I'm asking a follow up question.

In which circumstances should you, or should you not, report a stack-trace when you catch an exception? By "reporting" I include asking a logging framework to log the stack-trace for you.

I am not asking whether to report something. I'm asking whether that report should include the开发者_运维技巧 stack-trace.

I personally try to obey these rules:

• if I can handle the exception in the catch in a 'recoverable' way (e.g. a DateFormatException), no need to trace the stack

• if I want to rethrow the exception, log no stack trace. (rethrow in a chained way to retain this information)

• if I handle the exception in a catch block as an error case (e.g. sql error), I log the stack trace.

• if it's a runtime exception, I would suggest the framework (yours or whatever you use) does the tracing.

It's context dependent. For example, I might not log / report a ParseException from NumberFormat when parsing input from an external system, but I would definitely do so if I caught a ParseException which was dealing with data enclosed within the boundary of my system, since this would indicate an inconsistency in internal system state rather than an input value validation falure.

You - the developer - will need the stack trace if you are in an error situation. Hence you need some way of getting it out of the JVM and on to you.

If you do not log it to a file then what will you do? Files are the most reliable thing available in a JVM so you should at least put it there before sending it on the network.

A stack-trace is useful to a programmer who wants to debug a bug indicated by the exception. It is not useful to anyone else, for which the method names and call sequence are meaningless, and the verbosity is a distraction. Therefore, you should log a stacktrace if, and only if, and always if, the exception indicates a bug in the program. However, that does not always indicate that a method you write should catch and log the exception. In practice, bugs are indicated by unchecked exceptions, so it is easier (and often better) to let the exception be thrown from the method, and handled at a higher level: if you are using a framework, it will probably log the exception for you (often with additional useful information); the JVM itself will probably log any exception thrown from main.

I usually report exceptions not related to GUI. GUI Exceptions are common, and in heavy Swing programs usually happens.

Generally speaking, i'm deeply interested in: DB related exceptions, My-own-stupid-errors exceptions (array out of bounds, and stuff like that) and some other things that cannot be handled by me, like WebServices etc.

I think it depends the type of system, if it's a public one (like a website), or if it's private (intranet sites, GUI local)

I would report all of them. But if you are using log4j then you can control which ones you know for sure you will not be interested to see in the log. If a particular user exception has a different class, then disable logging in that class in production and enable it in lower environments. In that way, you are not doing anything at the code level for reporting. Its all abstracted at the logging framework.