Exceptions to java:S2095

SQ 8.6.

It seems that java:S2095, which relates to resources not being closed in a finally clause, has some parameterization. Through the Rules tab I only see the parameter excludedResourceTypes. Yet I’ve seen others mention other parameters for this rule. Are these hidden and I have to enable them somehow? Or have they been removed?

I’d like to add some exceptions, but I don’t think the parameter excludedResourceTypes does exactly what I want. I have some code where people added a call in the finally clause to a custom utility that closes the resource in question. Say, for example, the utility is foo(A,B) which (among other things) closes A. I’m wondering if there’s a way to customize the rule so that if foo() is called and x is the first argument to foo, then the rule won’t be triggered even if x is the resource that it thinks is not being closed properly. (I don’t mean dive into foo, just something that would let me add my knowledge of what foo does, something simple like “if x is the resource and foo(x,*) is called in the finally clause then don’t trigger this rule for x.”

Note that I still want the rule to work in other cases – this would be an exception, not a replacement. I wouldn’t want to use excludedResourceTypes to turn off the rule for all x because sometimes foo isn’t called, and I want those to be flagged still.


Well, no, there is no other possible parameterization of the rule available as external configuration, at SonarQube level. We also didn’t remove any parameters so far, and no other can be activated. All the fine-tuning of the rule is hardcoded directly into the Symbolic Execution engine the rule is relying on.

What you are describing here is called internally in our engine a “method behavior”. We already use this mechanism intensively, by computing some behavior on-the-fly during analysis, and use some hardcoded ones for well-known utility methods.

We have been thinking for a while about opening it and allow external configuration (letting users define their own “method behaviors” defined in their libraries), but so far it still needs to be discussed internally before committing to anything more concrete.

I hope this helps,