Originally posted by Jay Patel:
"What will happen in case like this?" In a case like that, you're in trouble. Unless I'm mistaken, you can't make that compile unless the implementing method throws neither exception. You can write it like this and it will compile:
This works because, when you override a method, you are allowed to throw any exceptions that are defined in the overridden method or any subset of those exceptions. In this case, we're throwing no exceptions, which is the empty subset of the exceptions defined in the overridden method.
However, the minute you try to throw an exception, you're in trouble. Let's say we want to throw SomeException1:
This won't compile because we're trying to override i1.test() which can throw SomeException1 and i2.test() which can throw SomeException2. Well, this works fine for overriding i1.test() because that method
can throw SomeException1. However, we get a compiler error on the overriding of i2.test() because that method can't throw SomeException1 - this breaks a rule of method overriding.
If you flip this around, or try to say that Test.test() can throw both exceptions, you'll get similar errors.
If you try to define two versions of Test.test(), one that can throw SomeException1 and another that can throw SomeException2, you'll run into another error - you now have two methods defined that have the same signature because the exceptions that can be thrown are not considered part of the method signature. Of course, having two methods with the same signature is a no-no.
So, what's the solution? Well, you're going to have to rethink your design in this case. Perhaps a simple rename of i2.test() to i2.test2() or something along those lines. As it stands right now, I don't see a way to make that compile.
I hope that helps,
Corey