Am 22.12.2016 um 22:15 schrieb Philippe Mouawad:
Hi,
Another note on sonar, do you agree with the rule:
- squid:S00112
That rule is the one about not to throw general exception, but to define
our own ones. I think we can disable that rule for the start.
Felix
Regards
On Thu, Dec 22, 2016 at 1:37 PM, Philippe Mouawad <
[email protected]> wrote:
Thanks Felix for your answers.
Mine below.
On Thu, Dec 22, 2016 at 12:20 PM, Felix Schumacher <felix.schumacher@
internetallee.de> wrote:
Am 21.12.2016 um 20:51 schrieb Philippe Mouawad:
Hello,
I reviewed Sonar errors and we have 2 major types of errors:
- Make "xxxx" transient or serializable:
- Should we ignore those ?
In the short run, we should definitely ignore those, as we know that we
are not really into serializing those objects, but we should strive to get
those fixed in the long run.
- If yes , I propose to add:
- <property name="sonar.issue.ignore.multicriteria"
value="squid:S1948" />
- @Felix, Is this correct ?
I will try it, but if you have found it in the docs, it should work,
shouldn't it?
I finally configured it in Sonar administration. You can have a look
- *Administration > General Settings > Analysis Scope > Issues*.
http://docs.sonarqube.org/display/SONAR/Narrowing+the+
Focus#NarrowingtheFocus-IgnoreIssues
We can also do it this way in ant:
http://stackoverflow.com/questions/21825469/configure-
sonar-sonar-issue-ignore-multicriteria-through-maven
- Either re-interrupt this method or rethrow the
"InterruptedException":
- Is the fix to call Thread.currentThread().interrupt(); in the
currently silent catch block ?
I always have to look it up, but I think that it is one way to handle it.
I'll start fixing this way. If anybody is willing to help on this, then we
can try to organize the fixing plan.
I prefer that we have precisely a look at each place where fix is
introduced to ensure it won't have side effects
Felix
Thanks
Regards
--
Cordialement.
Philippe Mouawad.
