Community
Participate
Working Groups
In Java, a method that goes toward implementing an interface does not have to throw all exceptions defined by that interface. This sometimes makes it hard to keep interface definitions in sync with the methods that implement them (especially when exceptions are eliminated from the implementing code). It would be nice if Eclipse had a warning for interfaces that indicated for a given method on the interface that "no implementing method throws this exception." This way, useless exceptions on interfaces could be eliminated, since any caller to the interface must catch all defined exceptions, whether they are actually thrown or not.
This is a nice suggestion, checking that implementations match definitions. Diagnostic to be reported during method verification.
It should say something like: "Method foo() of type X should declare throwing the exception type Bar, as defined by abstract method foo() of type Y" Rather than unused, I would suggest MissingAbstractMethodThrownException
I think the original suggestion was not to report anything in implementing classes (as Philippe discusses), but to flag the interface method declaring an 'unnecessary' exception. But that analysis would require to know "all implementing classes", which is not possible under Java's open world assumption, right?
Right.
Stephan is right - this is impossible to do. I suggest we close it as INVALID
Appreciate everyone's consideration.
I believe that we could still do something to improve the situation, if everybody feels like it. Considering the following code extract: import java.io.IOException; interface I { void foo() throws IOException; } public class X implements I { public void foo() throws IOException { // a } } class Y extends X { public void foo() throws IOException { // b } } Using the current IDE option 'Unnecessary declaration of thrown checked exceptions' valued to true with 'Check overriding and implementing methods' unchecked, we get no warning. Checking 'Check overriding and implementing methods' brings us two warnings (lines a and b). The former misses the warning on line a, the latter adds the somewhat extraneous warning on line b. A more balanced proposal could be to fully consider that only non-abstract methods have a chance to throw an exception, and to complain on line a even when 'Check overriding and implementing methods' is unchecked, recognizing that X#foo is the highest method in the hierarchy that would be capable of throwing the exception. The behavior on line b would then be tuned according to 'Check overriding and implementing methods'. (Note that this proposal may have consequences in terms of implementation practicality or performance, which may lead me to take it back. I also know that this introduces a change in the way we handle this warning.) What do others think about this proposal?
More tests show that the following code yields no warning, which should be addressed as well to round up the proposal (I believe this is more or less the point of Philippe's comment #2): import java.io.IOException; interface I { void foo() throws IOException; } public class X implements I { public void foo() { } } Unless we decide to do both, we do not address even a real part of the original bug, and the proposal of comment #7 should then become a separate bug - or not if we decide it's not worth further investigations.
Discussed comment #7 with Philippe. While the proposal could be considered as somewhat continuous with the cases that have no abstract method at all, the arbitrary choice of the topmost concrete method and the disruption that it would bring to the existing behavior were strong enough arguments to decide we would not want to do that. Also clarified that comment #2 stands as a potential contribution to this bug on its own merits (does not need the comment #8 proposal to bring value). Keeping the bug open with low priority to see if comment #2 gathers enough support to trigger an investment. Will close as WONTFIX else.
(In reply to comment #9) > Also clarified that comment #2 stands as a potential contribution to this bug > on its own merits (does not need the comment #8 proposal to bring value). > Keeping the bug open with low priority to see if comment #2 gathers enough > support to trigger an investment. In contrast to the original proposal, comment #2 is of course doable, but I wouldn't consider this desirable. Not declaring an exception that an abstract declaration declares is simply a form of conform redefinition, which actively states that this method doesn't make use of the right to throw a given exception. Thus, it is at the same level as covariant return types. Signalling either as a warning would more probably disturb people, rather than being appreciated. > Will close as WONTFIX else. I'd suggest to do so.
(In reply to comment #10) > In contrast to the original proposal, comment #2 is of course doable, > but I wouldn't consider this desirable. Not declaring an exception > that an abstract declaration declares is simply a form of conform > redefinition, which actively states that this method doesn't make > use of the right to throw a given exception. Thus, it is at the same > level as covariant return types. Signalling either as a warning Fully agree with this. > > Will close as WONTFIX else. > I'd suggest to do so. yes. Closing as WONTFIX.
Reopening to close as WONTFIX
Closing.
Verified for 3.7M7
