How can I change a Squid rule in Sonar?

Question

I'm new to SonarQube and Squid (and CheckStyle and FindBugs and PMD). I'm using SonarQube 4.1.1. and the default 'Sonar way with Findbugs' quality profile to evaluate some of my Java projects.

In the result of my analysis I get a ton of the same critical issue from Squid:

Exception handlers should provide some context and preserve the original exception When handling a caught exception, two mandatory informations should be either logged, or present in a rethrown exception:

• Some context to ease the reproduction of the issue.
• The original's exception, for its message and stack trace.

In my code I use a logger, e.g.

catch(Exception e) {
    LOG.error(SampleClass.class.getSimpleName() + ": " + e);
}

Why is this rule fired? The exception is logged. Is it, because I don't use a 'Logger' but a 'Log'?

A second question I have is: Where can I see and change the Squid rules and maybe add a couple of my own? As far as I understand FindBug, CheckStyle and PMD I can write my own rules. Is this possible with Squid too?

Answer 1

I believe the rule is being fired because you are logging the simple toString() message from Exception e, rather than the full stack trace. Something like

LOG.error(SampleClass.class.getSimpleName() + ": " + e, e); 

would satisfy the rule.

SonarQube has very good examples of compliant/non-compliant code with each rule definition. Expand the name of the rule, either in the issues or in Quality Profiles to see the examples.

You can alter (some aspects) of the default quality profile by creating a profile of your own that inherits from "Sonar Way..." and then change rules. You'll need admin access to your SonarQube to do that, then navigate to Quality Profiles to get started.

For example, our team decided that the particular issue you are looking at should not be Critical, given the number of times it occurs in our legacy code. We create our own profile inheriting from Sonar Way, and it is easy to lower the severity of this rule to Major. We have altered a number of rules, changing thresholds and/or regular expressions to better suit our needs. We haven't seen a need to write new rules, so I can't tell you how to do that, other than suggest checking the docs.

Answer 2

Try this

Log.e(TAG, e.getMessage(), e);

Answer 3

It is possible to define your own rules for SonarQube. Check out this question Sonarqube: Squid Rules customization/suppression for an ongoing attempt to keep the documentation link up to date.

Answer 4

This specific rule seems to me to be overly restrictive. How I handle exceptions needs to be more flexible. The old (pre-Squid) rules tended to complain about exception handlers that did nothing, whereas this rule now requires that every exception handler needs to share both the message and the stack of the original exception. I've downgraded the rule to minor for my team's project since we have almost 800 violations and few of them are important. I intend to deprecate this rule as soon as I get agreement from some others of the team. I'll go back to the old deprecated rule.

It seems to me that if my code is calling an external piece of code I don't need to share the stack trace through that piece of code when I report an exception. Somebody debugging my code with a NumberFormatException probably doesn't care how many layers the NFE went through in the number parsing, they likely just care that my code failed to validate the number and where to look for that fix in my code. Suppressing the original stack trace makes sense to me.