Sonar reports 6 bugs (2 rated blocker, 4 rated major)

Is it worth doing anything about this? https://sonarcloud.io/project/issues?id=dropwizard_dropwizard&resolved=false&types=BUG

I’ve raised a few MRs to address sonar issues in the past where there were clear ways to both improve the code and also quieten the Sonar report, but the remaining group of 6 issues I’m either not sure about or seem like false positives.

I don’t think having sonar grumbling is necessarily a bad thing, but if it’s configured it would be nice if it had a clean report.

The issues:

• dropwizard-auth ChainedAuthFilter can potentially throw an exception which can potentially be null. I’m not sure what the correct thing to do here is. ✔️ addressed with https://github.com/dropwizard/dropwizard/pull/4376
• dropwizard-db TimeBoundHealthCheck could potentially swallow an InterruptedException. This is possibly bad - should an extra catch clause be added? I’m not sure and threads scare me. ✔️ addressed with https://github.com/dropwizard/dropwizard/pull/4239
• dropwizard-lifecycle ExecutorServiceBuilder ignores the result of String.format, but intentionally so as it’s using the call to check that the format string is valid. Sonar will stop complaining if it’s wrapped in an explicit try-catch, but adding unnecessary code just to please Sonar isn’t great. @SuppressWarnings("ResultOfMethodCallIgnored") doesn’t seem to appease Sonar - is there anything else which will? ✔️ addressed with https://github.com/dropwizard/dropwizard/pull/4277 - dropwizard-logging LoggingUtil - another potential swallowing of an InterruptedException. I have no idea what the right thing to do is here and messing with threads and logging frameworks doubly scares me. ✔️ addressed with https://github.com/dropwizard/dropwizard/pull/4239 - dropwizard-logging ResilientSocketOutputStream creates a Socket but doesn’t close it. This is entirely intentional as the method returns an active connection. ✔️ addressed with https://github.com/dropwizard/dropwizard/pull/4278 - dropwizard-logging DropwizardUdpSocketAppender creates a DatagramSocket but doesn’t close it. This is entirely intentional as the method returns an active connection. ✔️ addressed with https://github.com/dropwizard/dropwizard/pull/4278

I’m not convinced any of these are real issues, although I admit to not being very confident about the thread-related ones.

What to do? Close this issue and let Sonar carry on grumbling to nobody in particular, add some suppression magic somewhere or make some code changes?

Mostly I’m raising this to say “I’ve looked at all the issues Sonar reported as major and I’m left with these. Is there anything I can do to clean stuff up further?”

[rhowe]

dropwizard-lifecycle ExecutorServiceBuilder

The JavaDoc of String.format references java.util.Formatter. Maybe one could refactor the code to something like new Formatter().format(...).close(), as this would be a void call then.

This looks viable. PR here: https://github.com/dropwizard/dropwizard/pull/4277

[rhowe]

2. Abort your work and restore interrupt state (without throwing it) - which seems to be your case

Alright, I’ve raised this for consideration: https://github.com/dropwizard/dropwizard/pull/4239