CODEWITHSUNDEEP
javaloggingexception
shinynewbike
shinynewbike

Reputation: 2352

what's wrong with e.printStackTrace() for an unknown exception

If I use a logger in the case of known exceptions, what's wrong with e.printStackTrace() for an unknown exception ?

I'm always told not to do this - but not given a reason

example below

try {
            dostuff();
        } catch (AException ae) {
            logger.error("ae happened");
        } catch (BException be) {
            logger.error("be happened");
        } catch (CException ce) {
            logger.error("ce happened");
        } catch (Exception e) {
            e.printStackTrace();
        }

Upvotes: 11

Views: 5635

Answers (6)

Kevin Panko
Kevin Panko

Reputation: 8534

This is bad because e.printStackTrace() will not necessarily write to the same log file as logger.error() so for consistency you should use logger.error() for everything.

Nor does e.printStackTrace() do anything to describe what was happening that caused the error. You should always include a log message that will make that clear to the person who reads the log file.

If you send the exception object as the second parameter, and you will get the stack trace in your log file, as well as the exception's message string. The poor soul reading the log file will be glad to have this information available.

try {
    doStuff();
}
catch (AException ae) {

    // Send to the log file a message describing what we were doing,
    // and what happened as a result

    logger.error("ae happened, while attempting to do stuff, but that's okay", ae);

    dealWithTheSituation();
}
catch (Exception e) {

    logger.fatal("an unexpected error happened, while attempting to do stuff, cannot proceed", e);

    abortAndCatchFire();  // Burn the evidence
}

Upvotes: 3

Manuel Salvadores
Manuel Salvadores

Reputation: 16525

Because it doesn't use the logger system, it goes directly to the stderr which has to be avoided.

edit: why writing directly to stderr has to be avoided ?

In answer to your question, @shinynewbike, I have slightly modifed my answer. What it has to be avoided is to write directly to stderr without using a logger capability.

loggers provide useful features to change logging traces by priority and packages, among other things they also allow to redirect traces to different output mechanisms ... queues, files, databases, streams ...

When you write directly to System.err or System.out then you lose these features, and what is worse if you mix logger and System.err.write you might end up getting traces in different 'files' which will make debugging your system difficult.

Upvotes: 15

Eric
Eric

Reputation: 2348

One of the things that the logging framework is giving you is a powerful abstraction over where your log messages are finally output. You may think you can achieve the same with standard out and standard error, but this is not always the case. In many environments, the developer does not have any control over what happens to the standard io streams in an app.

The most common scenario is that your app is runing inside another container such as tomcat, which may output its own messages to standard out. Since your app is running in the same process, all your messages will get mixed together with the container's along with any other application's messages running in the same container.

Using a logging library gives your app the flexibility to log messages to a number of different destinations which can be configured by the deployer. You won't get this benefit when you use e.printStackTrace().

There are a few other issues raised by the example you've given btw. Some follow up questions might be:

  • When is it ok to catch(Exception ex)?
  • When/how should exceptions be logged?

Upvotes: 2

Martin Ring
Martin Ring

Reputation: 5426

catch (Exception e) catches all exceptions even the unchecked ones which derrive from RuntimeException like NullPointerException or IndexOutOfBoundsException and the program then continues to run even though it is highly likely that you dont want that because those are often fatal and can exit the control flow at unexpected positions.

If you expect one of those unchecked exceptions then you should explicitly catch that type of exception and handle it.

Upvotes: 1

lamwaiman1988
lamwaiman1988

Reputation: 3742

First of all, printing stack trace doesn't solve the problem, and the problem will probably not report to the parent thread for further handling. My suggestion is that you handle the exception in the catch clause, by identify the type of exception in the program using e.getClass().getName().

Upvotes: 0

Peter Lawrey
Peter Lawrey

Reputation: 533530

IMHO, You should

  • consistently log to a logger OR standard error, but not a mix (perhaps this is the reason for the complaint)
  • always log exception with the stack trace unless you are sure you will never need it.

Upvotes: 7

Related Questions