Should we log the stacktrace for managed exception?

Question

I made many research on this subject without found a real answer.

Try to imagine a program which execute a multi thread calling a Callable. For that, we launch an ExecutorService with a specific timeout which invoke all process.

So we have a try...catch block with multiple exception :

• CancellationException for a timeout
• ExecutionException if an exception is raised in the thread
• InterruptedException for an abrupt stop...

Is the philosophy to log an message only, or to log the message and the throwable (so the stacktrace) ?

To sum up, should we do this :

} catch (CancellationException ce) {
    logger.error("Timeout. Process cancelled", ce);
}

or just log the message error ?

Is stacktrace considered to appear only for bugs ?

Thank you.

Answer 1

For coding you should stick with the following pattern:

} catch (CancellationException ce) {
    logger.error("Timeout. Process cancelled", ce);
}

The reason is that the Throwable captures the complete context of an error. If you omit parts of that context from the logger you'll never be able to access it later on if you need it. Even the Throwable class included with Java has been modified over time to include things like chained and suppressed exceptions. So even if you only want the message from this throwable you still might want to see the full stack traces for suppressed exceptions and exceptions causes.

On the output side, I think you can make that case that for some exceptions the stack trace is not important. In some cases the target audience must not or does not want to see exception stack traces. For these cases should leverage the features of the framework to change the published output to please the target audience. If the needs change over time you can tweak logging configuration without having to fix the application code.