In no case should there be a warning if the exception is wrapped and re-thrown. For example:

try {
    ...
} catch(Exception e) {
    throw new RuntimeException("error", e);
}

(In reply to comment #0)
> While the reasoning behind the "exception is too broad" hint is valid, in many
> people's judgement the more concise code produced by the anti-pattern of
> catching an overly broad exception outweighs doing things the "proper" way and
> repeating code in each catch block. Multicatch (and its more concise code)

It is the purpose of the hint to alert of a *possible* issue. I can make the hint more complex, but still the IDE cannot reliably determine whether the reason to catch 'broad' exception is valid and conforms to the team's coding style or requirements on that particular place.

I agree that JDK 7+ syntax decreases the need for the anti-pattern, but IMHO the hint does a valid job even in < JDK 7, in that it warns before possible unintended effects when catching broad exception type subtree - we used successfully similar hint in IntelliJ IDEA in my past projects to pinpoint places which are worth human inspection.

Personally I find the anti-pattern more harmful as it leads to suprises in exception handling as the code in the guarded block changes and starts to throw additional exceptions - espectiall with 'catch all' clauses like 
catch(Exception ex) {}, or 
catch (Exception ex) { 
  if (ex instanceof Foo) { ...} 
  else if (ex instanceof Bar) { ... }
}
Replicating is not that bad, you need not to replicate more complex code can be factored out to an error handling method.

When the place is determined NOT to be harmful, it may be annotated with @SuppressWarnings() - I'll add a relevant code for this hint; sorry I forget to define one.

As with all hints - if the hint generates too many false positives, according to your opinion, or your favourite coding style, you may turn the hint off. With per-project hint settings, you may even turn the hint off selectively for projects that use JDK < 7.


(In reply to comment #1)
> In no case should there be a warning if the exception is wrapped and re-thrown.
Following the reasoning of the previous comment, the bad effect of this snippet is that leads the maintaining programmer to not care about proper error handling of even checked exceptions and it proved to be a source of errors (error handling errors :)) during code reviews I did in the past. It's better to check such places during code review to ensure proper error handling and that's why they are reported.

BTW one should never throw RuntimeException in production code. An application/feature specific subclass should be created, so the ill application state can be distinguished from programming errors (NPE, or UnsupportedOperationExc are also RuntimeExcs), but that was probably only meant as an example :)

There are many ways how to deal with a catched exception; and the proper one can be only determined by the programmer, depending on contract of the surrounding code:
throw new XXXException(original);
LOG.log(LogLevel.INFO, original);
Exceptions.printStackTrace(original);
....

SupressWarnings hints added in http://hg.netbeans.org/jet-main/rev/a1e1c809a479

Good idea; I forgot about the @SurpressWarnings option. IMO there still should not be a warning if the exception is re-thrown, but your call.

And now that I think about it @SurpressWarnings only is fine; once the per-project hints are added for Maven I can handle the legacy code that way.

Integrated into 'main-golden', will be available in build *201305182300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/a1e1c809a479
User: Svata Dedic <sdedic@netbeans.org>
Log: #229479: Added @SuppressWarning codes

yup.

BTW, are this hint and the "use specify catch" hint similar enough that they can be combined?

...the use *specific catch hint.