Exception Handling Policy – Logging Exceptions
This is the last part of my series on exception handling which will deal with logging exceptions and other noteworthy events.
A summary of the series:
- Throwing Exceptions
- Using Assertions
- Catching Exceptions
- Logging Exceptions (this one)
General guidelines
We’ll start off with a few general guidelines for logging.
Always include the exception message in the log
Make sure you know what actually went wrong, not just that something went wrong.
Never lose a stack trace!
And not only do you want to know what went wrong, you want to know where! An exception without a stack trace is like a person with no memory.
Debug levels
A summary of the typical severity levels used when logging and guidelines on when to use them.
Info, Debug, or Trace
Informational messages that highlight the progress of the application at various levels of granularity.
Use logging levels INFO, DEBUG, TRACE.
Warnings
Potentially harmful situations, such as invalid requests which could be some form of attack. It could also be a client (developer) in need of help.
Use logging level WARN.
Errors
Error events that might still allow the application to continue running. For example, uncaught exceptions in your “catch all” exception handler.
Use logging level ERROR.
Fatal errors
Very severe error events that will presumably lead the application to abort. Examples include all fired assertions. They should not happen — they are bugs! Also, all “errors” in the Java sense (out of memory etc).
Use logging level FATAL.
I hope this quick four part series on sensible exception handling has been interesting. Be sure to read the previous installments (see summary at top) and please feel free to add your comments below! Any and all comments are very welcome!