Throw exception vs Logging

The proper answer would be: "it depends"

You do want in general log the exceptions that you catch, since they correspond to something going wrong. That is why code analysis tools such as sonar will raise warnings when you do not log them.

Consider the following taks: parsing a file. While parsing the file you actually try to parse each line. Sometimes some lines will be malformed, and therefore you don't want to stop parsing the file because of it. In that case, you probably want to just log the wrong line and keep going on the file. However, imagine that at some point you encounter an I/O exception while reading (for example some other program deleted the file while yours was accessing it).

In this case, you will probably want to log your log the error you encounter, and throw a new exception to stop processing the whole file.

So in short, you have to think about what is the best thing to do. But both practices are not bad.


Normally, I'd argue that you should either log or rethrow. Doing both will just cause every layer to log the exception again and again, which makes the logs hard to read. Even worse, it's hard to figure out how many errors you actually have - was it seven errors, or seven layers of the app which logged the same error?

This means that if you suppress an exception, you log it and say why you didn't think it was worth rethrowing.

On the other hand, if you re-throw the exception, you know it's either going to be caught and suppressed (in which case the catcher logs the exception and why it was suppressed), or it will bubble up out of your app and be caught by the app container, which will catch and log the exception. Every exception shows up once and only once in the logs.


When using the pattern you suggest, you usually end up with error events being reported multiple times in the log. In addition, it's not always simple to connect between them when reading the log.

Personally I prefer logging error events only once, and doing it in the higher call levels. Therefore I almost never log & re-throw. I usually let the exception go up the call stack until it reached a context where it can be handled somehow, and this is where I log.

If the exceptions are wrapped and re-thrown correctly, the context should be perfectly clear from the stack traces of the single log message.


I use both in some cases, logging and throwing the exception. Specially, it's useful in APIs. By throwing the exception, we allow the caller to handle it, and by logging, we can identify the root cause of it ourself.

And, if the caller is in the same system, then if we add logs in every catch, there will be duplicate logs.