Community
Participate
Working Groups
Hi, the compiler option "Unnecessary declaration of thrown exception" has still a bug: If an interface method, that throws an exception, is implemented by a class, this option shouldn't indicate an unnecessary exception if the method is part of an interface that declares throwing this exceptions. If I remove the throws declaration and if I have a child class that overwrites this method, I get an error. Compiling the following example, gives an "Exception JDOMException is not compatible with throws clause in "EveryTimeTrueTest.doTest" error: interface Iface { boolean doTest throws MyException; } public class EveryTimeTrueTest { boolean doTest { return true; } } public class DoARealTest extends EveryTimeTrueTest { boolean doTest throws MyException { if (some_test) { throw new MyException(); } return true; } } Adding the throws declaration in EveryTimeTrueTest gives an "The declared exception JDOMException is not actually thrown by the method doTest() from type EveryTimeTrueTest". BTW: The "Problems"-View wouldn't be updated if I save a changed class. It is only updated when I compile or recompile the project. I think this is a bug, too.
Sorry, I forgot to write that I found this bug in version 3.0 M4.
The warning is only a local indication for the method carrying unused exception declarations. Looking at subtypes would be super expensive, and would make it unusable. Though I agree the situation you ran into is a valid usecase, we don't have a good answer to it.
You don't need to look at the subtypes. Looking at the interface that the class implements would be enough and this shouldn't be super expensive. I think, if the behavior wouldn't be changed, this option wouldn't be helpfully.
Re: looking at subtypes is expensive You only need to do this when you have already detected the Exception is not needed which shouldn't be too frequent. It could at least be an option.
Then all you're asking instead is that if the method is defined in a super interface, then no complaint should be issued, right ? This is something quite easy indeed, which we had in mind (see what we do for unused arguments for instance), but this doesn't capture the scenario where you do not use an interface, and simply define a top concrete method which subclasses are then overriding. I agree though that this would cover most usecases.
Yes, that's what I mean; if the method in the interface declares the unused exception, then no complaint should be issued. It is right, that the case, where an exception is declared but not thrown in a top concrete method which subclasses are then overriding, isn't covered, but it wouldn't be possible to fulfil all cases. For example: what is, if the subclasses aren't part of the project? The only way to cover this case, would be the possibility to set a marker for such a method, so that for the unused exceptions of this method no complaint should be issued. This marker could be saved somewhere the project.
Any marker should be stored in the source code, you could just treat an @throws javadoc as a marker. An alternative to markers would be to create an interface for any method that gives this problem.
Added option to ignore overriding methods (by default they will be ignored).
Regression test added: NegativeTest#test407 & test408.
Verified for 3.0M7 Currently there is no UI to modify this option (bug 51823).
Martin will try to add it.
*** Bug 49163 has been marked as a duplicate of this bug. ***
