Avoid printStackTrace(); use a logger call instead

It means you should use logging framework like logback or log4j and instead of printing exceptions directly:

e.printStackTrace();

you should log them using this frameworks' API:

log.error("Ops!", e);

Logging frameworks give you a lot of flexibility, e.g. you can choose whether you want to log to console or file - or maybe skip some messages if you find them no longer relevant in some environment.

If you call printStackTrace() on an exception the trace is written to System.err and it's hard to route it elsewhere (or filter it). Instead of doing this you are adviced to use a logging framework (or a wrapper around multiple logging frameworks, like Apache Commons Logging) and log the exception using that framework (e.g. logger.error("some exception message", e)).

Doing that allows you to:

• write the log statement to different locations at once, e.g. the console and a file
• filter the log statements by severity (error, warning, info, debug etc.) and origin (normally package or class based)
• have some influence on the log format without having to change the code
• etc.

A production quality program should use one of the many logging alternatives (e.g. log4j, logback, java.util.logging) to report errors and other diagnostics. This has a number of advantages:

• Log messages go to a configurable location.
• The end user doesn't see the messages unless you configure the logging so that he/she does.
• You can use different loggers and logging levels, etc to control how much little or much logging is recorded.
• You can use different appender formats to control what the logging looks like.
• You can easily plug the logging output into a larger monitoring / logging framework.
• All of the above can be done without changing your code; i.e. by editing the deployed application's logging config file.

By contrast, if you just use printStackTrace, the deployer / end user has little if any control, and logging messages are liable to either be lost or shown to the end user in inappropriate circumstances. (And nothing terrifies a timid user more than a random stack trace.)