# S2139 should not be triggered for this specific case

**URL:** <https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625>\
**Category:** Report False-positive / False-negative...\
**Tags:** sonarqube, java\
**Created:** [February 7, 2019, 5:38pm UTC](https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625 "2019-02-07T17:38:15Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![remibantos](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/remibantos/32/2469_2.png) [@remibantos](https://community.sonarsource.com/u/remibantos)\
**Post date:** [February 7, 2019, 5:38pm UTC](https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625/1 "2019-02-07T17:38:15Z")

</div>

Sonar Qube version

- Version 6.7.6 (build 38781)
- Language Java

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

```auto
} 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](https://www.flowable.org/docs/javadocs/org/flowable/engine/delegate/BpmnError.html) 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**

---

<div class="post-metadata">

**Author:** ![saberduck](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/saberduck/32/27_2.png) [@saberduck](https://community.sonarsource.com/u/saberduck)\
**Post date:** [February 11, 2019, 4:32pm UTC](https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625/2 "2019-02-11T16:32:31Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![remibantos](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/remibantos/32/2469_2.png) [@remibantos](https://community.sonarsource.com/u/remibantos)\
**Post date:** [February 11, 2019, 6:14pm UTC](https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625/3 "2019-02-11T18:14:20Z")

</div>

Hi @saberduck ,

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.

> [@saberduck](#):
>
> How often do you encounter this kind of issue?

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

> [@saberduck](#):
>
> Maybe you could instead pass the stacktrace as part of the message

I would not recommend this workaround

---

<div class="post-metadata">

**Author:** ![remibantos](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/remibantos/32/2469_2.png) [@remibantos](https://community.sonarsource.com/u/remibantos)\
**Post date:** [March 27, 2019, 6:20pm UTC](https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625/4 "2019-03-27T18:20:02Z")

</div>

Hi @saberduck, should I report a bug for that?  
For now I have excluded all these false positives explicitly in the code.

---

<div class="post-metadata">

**Author:** ![saberduck](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/saberduck/32/27_2.png) [@saberduck](https://community.sonarsource.com/u/saberduck)\
**Post date:** [April 1, 2019, 8:18am UTC](https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625/5 "2019-04-01T08:18:55Z")

</div>

hello @remibantos ,

just to better understand your context, do you consider the rule to be otherwise valuable?  
I have created this ticket to add exception to the rule implementation [https://jira.sonarsource.com/browse/SONARJAVA-3073](https://jira.sonarsource.com/browse/SONARJAVA-3073)

Note that, fix version is tentative.

---

<div class="post-metadata">

**Author:** ![remibantos](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/remibantos/32/2469_2.png) [@remibantos](https://community.sonarsource.com/u/remibantos)\
**Post date:** [April 2, 2019, 10:01pm UTC](https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625/6 "2019-04-02T22:01:27Z")

</div>

Thanks for the ticket

I think this rule is usefull, as it is generally a bad idea to log many times the same exception…  
It just needs to be adjusted in order not to catch this specific case as you explained.

---

<div class="post-metadata">

**Author:** ![sdoeringNew](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sdoeringNew](https://community.sonarsource.com/u/sdoeringNew)\
**Post date:** [April 30, 2019, 2:27pm UTC](https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625/7 "2019-04-30T14:27:53Z")

</div>

I see that as false-positive, too.

And even the description of that rule confirms that: “Exceptions should be either logged or rethrown but not both”

In @remibantos case the exception is logged but it is not rethrown. Instead a new exception without the cause is thrown. So there will be no stacktrace-cascading and the rule does not apply.

Even more: “In applications where the accepted practice is to log an Exception and then rethrow it, you end up with miles-long logs that contain multiple instances of the same exception.” - that is not the case.

---

<div class="post-metadata">

**Author:** ![remibantos](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/remibantos/32/2469_2.png) [@remibantos](https://community.sonarsource.com/u/remibantos)\
**Post date:** [April 6, 2022, 2:33pm UTC](https://community.sonarsource.com/t/s2139-should-not-be-triggered-for-this-specific-case/6625/8 "2022-04-06T14:33:20Z")

</div>

Hi,  
I had provided the Sonar version, 6.7.6, but looks like it was not reproduced with the same Sonar version in [[SONARJAVA-3073] S2139 shouldn't raise issue when cause can not be passed in constructor - SonarSource](https://jira.sonarsource.com/browse/SONARJAVA-3073)  
Could you please try again to reproduce with this ?  
Thanks