The rule java:S1166 states that passing e.getMessage to the log message would be complaint, but it’s not recognized here using slf4j logging framework:
Furthermore, no issue will be raised if the exception message is logged with additional information, as it shows that the developer added some context to the error message.
I find it really strange to consider that logger.info(e) is valid and not logger.info(e.getMessage()) while the only difference is the class name of the exception in the log and in both case the stacktrace is lost
The rule with the exceptions is useful, because otherwise your log is always full of stacktraces which normally should not be needed to determine the cause of the problem.
I can understand that exception to rule is useful.
But i am failling to see how LOGGER.info(e.getMessage()); can be non compliant as the exception is lost while LOGGER.info(e); is considered as compliant as it considers that the exception is better logged and doesn’t violate the issue rationale :
When handling a caught exception, the original exception’s message and stack trace should be logged or passed forward.
It isn’t a compliant solution. It should at least be in the exception part, like the mention
Furthermore, no issue will be raised if the exception message is logged with additional information, as it shows that the developer added some context to the error message.
So either the rule S1166 has a bug or the java analyzer has not a proper sonar.java.binaries configuration to resolve the org.slf4j.Logger method invocation.
About a potential bug, I failed to reproduce the false-positive with the following code snippet: