Community
Participate
Working Groups
Build ID: I20070503-1400 (3.3 M7) Steps To Reproduce: class Foo { public blah() throws SomeException { // not really thrown int foo; // unused } } More information: http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm shows the list of warning types that ought to be supported by SuppressWarnings. There are 2 warnings output with the example code: declared exception not thrown and unused local variable. I should be able to hide just the unused exception warning by adding @SuppressWarnings("unusedThrown") above the method. But this isn't recognized. Adding @SuppressWarnings("unused") hides ALL the unused* types of warnings. I need to be able to hide the unused exception, but continue to see the unused local variable warning.
This would mean "unusedThrown" should be added in the list of supported tokens by SuppressWarnings. Too late for 3.3.
The list referenced by the http link shows a BUNCH of warning types that should be supported. While this bug report targets just one, the entire list should be supported.
The list was reduced on purpose. This would be an enhancement for 3.4.
The idea behind was to decide whether a warning should be suppressable, or simply fixed. Some are rather plain things to fix, and for these obvious ones we did not introduce warning tokens. Some are arguable, and for these we generally introduced a warning token (unless we forgot a few). As for 'unusedException', I wouldn't go that specific, if we don't want to end up with myriad of warning tokens. For unused thrown exceptions, I think we should consider a solution like the one we chose for unused params (i.e. consider documented references from javadoc). /** * @throw SomeException */ If documented, then we would stop complaining.
In my particular case, I have an interface method that declares 3 exceptions to be thrown. One class that implements the interface throws all 3 of the exceptions. But another class that implements the interface throws only 2 of them, so I constantly have this one exception declared but not thrown. Suppressing "unused" hides that, as well as any unused locals - which we really do want to catch. Another way to "forgive" this would be to look up the hierarchy to see if the method is inherited. Seems like that would be a better basis for forgiving the unused exception than to rely on Javadoc.
Inheritance situation is normally supported already, see compiler preferences. There is a sub-option named "Check overriding and implementing methods". If it is disabled it will behave exactly as you described (or at least it should, unless you found a bug, and if so pls enter a separate bug). Now, one more thing, assuming your scenario looks like this: interface I { void foo() throws SomeException; } class A implements I { void foo() throws SomeException {} } and you enabled the mentionned suboption, you will get a complaint on A#foo(). One thing you can do is remove the throws clause, since the language allows throwing less exceptions than super method. i.e. the following is legite: interface I { void foo() throws SomeException; } class A implements I { void foo() {} } Now, this may be troublesome for subsequent subclasses of A which cannot throw any longer... so it is likely preferrable for you to ensure the suboption is disabled.
Thx for the heads up on the compiler option. I also have this scenario: public class RS { protected foo() throws AEx, BEx, CEx { // AEx and BEx are thrown; CEx is not } } public class FS extends RS { protected foo() throws AEx, BEx, CEx { // All 3 exceptions are thrown } } I still get the unused exception warning in RS. This is a base class, so it's not an overriding method, so the compiler option has no effect. If I remove CEx from the throws clause, then we get an error, as expected. So I think something like unusedThrown is my only way to forgive this condition.
Wouldn't you rather have the javadoc clause tell the compiler that the exception is part of the API, and thus stop barfing ? We implemented this behavior for unused parameters, which can meet the same issue. If you like it, we could also leverage this for unthrown exceptions (consistent story). i.e. public class RS { /** * @throws AEx * @throws BEx * @throws CEx */ protected foo() throws AEx, BEx, CEx { // AEx and BEx are thrown; CEx is not } }
I guess I'm a purist, so having something in the documentation that causes the compiler to forgive various warnings just kind of rubs me the wrong way. Especially if there's something in that language itself that provides a way to handle that (annotations). I don't like the fact there's not a standard set of annotations for these these warnings. We use Eclipse on our dev machines but javac to actually build the code we ship. (Silly, I know.) So we'll get rid of the warnings in Eclipse just to have them pop out again on the build machine. That being said...if you've solved with javadoc for unused params, and I understand the desire for consistency, then that could work just as well.
Javac is not diagnosing unthrown exceptions afaik. Now, you can disable this for Eclipse compiler as well (and btw, you can run Eclipse compiler in batch/command line as well to be consistent). The reasoning for using javadoc, is that it is part of your API specification. Forcing users to use annotation (and you have one today for suppressing warning which is going to work, just doesn't have the granularity you'd expect) is first requiring them to use 1.5 or better; which isn't a solution for everybody, besides the fact there is no standard set of warning tokens (i.e. you could imagine various compilers to define their own custom warning tokens).
I understand the logic...makes sense. Thanks very much for the comments. Possibly would want to update the doc so that the list of warning types referenced in the help (in the original bug report) is not misinterpreted as usable in annotations as I did.
Closing, no further action planned.
