Once a project has been delivered, Logging can be the only resource developers have to debug an application. It can also be the only source of information for support staff. To reduce unnecessary noise, a finely crafted application should have no exceptions visible in the logs or the console unless something unexpected occurs.
If you deploy an application to the customer for testing, ensure that there is a process for them to zip up the logs and forward them to you at the end of each day. Trawl through the logs looking for errors and Exceptions and fix any you can. You will be surprised what you forgot to handle.
Log levels:
Frequently done incorrectly, following are descriptions of when to use an appropriate log level.
| Log Type |
Description |
| ERROR (or SEVERE) |
These are for errors in the application, for situations that are never expected to happen, such as a model class being in the wrong state, or unable to open a file that has to be there. Unexpected exceptions go here, but NOT expected exceptions. Most Error messages in the log should be investigated and the problem ultimately resolved. If the problem can not be resolved, perhaps consider that it should not be an error after all. It is appropriate to log a stack trace with the error, as there should be no stack traces in the log when the system is running smoothly. |
| WARNING |
These are for error conditions that are expected, but need to be logged. For example, when a user tries to log in with an incorrect password, log a warning. Being unable to connect to LDAP to validate the user password is an Error, not a warning. There should be no stack traces logged with warnings. |
| INFO |
These are for general information about what the application. While similar to debug, these may be left visible in production if useful. |
| DEBUG |
These are used for developer debugging and should never be seen in production. |
Operations staff only want to be alerted by critical errors they can escalate or fix directly by following step-by-step instructions the operations manual. Likewise if logging goes to a central alarming system, the only critical issues raised should be things that can be directly resolved. After all, there is nothing an operator can do if a user tries to log in with an invalid username and password combination – keep those errors for internal application logs only.
Trap: If you find the urge to internationalize all messages in your logfiles, first check if you have sand blasted your oven, flossed your cat or updated the resume you may need soon. Life is too short.
