S2139 should not be triggered for this specific case


(Rémi Bantos) #1

Sonar Qube version

  • Version 6.7.6 (build 38781)
  • Language Java

This rule, squid:S2139, should not be triggered for this specific case:

} catch (AnyException ex) {
    LOGGER.warn("I want to log the stack somewhere", ex);
    // Third party library exception which does not support instantiation with the Throwable cause
    throw new ThirdPartyLibraryError("code", "message");

In this example I want to log the root exception, and throw another third party exception which does not provide the ability to instantiate it with the Throwable cause. (there is only one constructor with error code).

Note that this ThirdPartyLibraryError exception, depending on its content, has impacts on the way this third party solution behaves (In the real life, I’m throwing a BpmnError which is used by a BPMN business process).

IMO, this rule should only be triggered when both logging and throwing another exception instantiated with the cause

(Tibor Blenessy) #2

Hello @remibantos,

this seems to be a quite peculiar case to me to justify the change in the rule. How often do you encounter this kind of issue? Maybe you could instead pass the stacktrace as part of the message?

(Rémi Bantos) #3

Hi @saberduck ,

I would not qualify this case “peculiar”.
For now we have added a temporary @SupressWarnings as a workaround in many classes where this pattern is applied.
Since last update of Sonar Qube, we get a lot of major false positive bugs for this reason.

Each time one of the class (many) where we use such pattern gets analyzed.

I would not recommend this workaround