Any reason not to always log stack traces?

Question

Encountered a frustrating problem in our application today which came down to an ArrayIndexOutOfBounds exception being thrown. The exception's type was just about all that was logged which is fairly useless (but, oh dear legacy app, we still love you, mostly). I've redeployed the application with a change which logs the stack trace on exception handling (and immediately found the root cause of the problem) and wondered why no one else did this before. Do you generally log the stack trace and is there any reason you wouldn't do this?

Bonus points if you can explain (why, not how) the rationale behind having to jump hoops in java to get a string representation of a stack trace!

Answer 1

• Some logs might contain sensitive data, log facilities are not necessarily secure enough to track that data in production.

• Logging to much can result in too much information, i.e. no information at all for the sysadmins. If their logs are filled up with debug messages, they won't be able to recognize suspicious patterns. (Years ago I saw a system logging all system calls for security reasons. There were so many logs, that nobody saw it when some unprivileged users started to become root.)

Best thing to do to log everything with appropriate log levels, and be able to set log levels in production (at least in Java not that a big issue).

Answer 2

Please see these questions also

Logging in Java and in general: Best Practices?

Best practices for Java logging from multiple threads?

Important things here to consider

1. Handling Sensitive data
2. Compact exception messages and mailing those to appropriate fixers
3. Logging what is required. Because its logging expensive in terms space and time