What resources are available to convince the developer that Java stack traces are worth the log

Question

I just landed in a new code base. Working to ensure that the application runs locally, I noticed that I was just getting single-line characters for errors in the log and console output — no stack traces. I started searching for the code, and the only thing I could find was an exception message. The same goes for the exception chain: only the message was saved. I mentioned this to the sole developer of the project and asked if it was an intentional design decision. The answer was, in particular: "I do not think that we learn much from [logging stack traces]."

From the years of Java development, I know how valuable stack traces are: they tell you which line the exception occurred on, and you can track how you got there. You read the stack trace and the corresponding code, and probably enough to solve 80% (NB: statistics have no statistical support) of the errors you encounter.

I am not looking for arguments about what to do with the magazine or when - this is not a question, and it was considered elsewhere. In fact, it just seems to me such a fundamental thing that I never thought about how to explain it, except that "trace tracks show you where the error was." I was hoping I could quickly find a quote from Efficient Java or the like, but Google hasn’t found anything yet.

Any suggestions from reputable, compelling sources to describe why you should pay attention to stack traces?

Answer 1

Create a deliberate error in the code base and make it track it :-). Seriously, you have good arguments if you can just demonstrate how much this helps and how much time it saves in tracking errors.

Answer 2

Perhaps the Google Coding Standard for Java will be considered quite authoritative:

Exceptions All methods must throw an exception due to the lack of lead time that they can throw their brochure. If they can drop a few, everything should be listed, although they shorten the list of basic classes, and not all of their children are encouraged, information is not lost. In particular, the “throws an exception” never appears by any method, except in extreme cases, such as methods that are so general that they can actually be an exception.

Likewise, catch (Exception e) should not be used anywhere, as it can catch exceptions that should not be caught and thus hide problems. the exact exceptions that are caught should be stated instead.

For similar reasons, empty trick blocks should be avoided (except for the verification code, in which exceptions are expected), as they can also hide problems and make debugging difficult. If you know that an exception can never always raise an OntopiaRuntimeException with a message like "(IMPOSSIBLE)" + e ", and pass in the excluded exception to save the stack trace.

Answer 3

I found that the Apache Commons Logging, which is used for this project, contains these guidelines for logging exceptions that indicate logged with a full stack trace.

Anyway, I would like to find something that directly suggests that this should be the default behavior unless you have a really good reason for this. Going into details about why this is a good idea would be even better.