On 1/17/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
I don't think you need to remove catch blocks from user code. If the
try/catch
is left in, then the user would get the warning that we're getting.
No, this is a different situation.
void someMethod() throw SomeException {
//Not a compile error. someMethod() may be intended to be overridden,
//so this may be fine.
}
try {
//any code here that doesn't declare throws SomeException
}
catch(SomeException e) {
//Compile error. It is impossible that SomeException would ever get thrown.
}
But you are correct in saying this breaks APIs - in the following way, I
think:
If the user subclasses an API which has a "throws xxx", the throws xxx
clauses
on methods being overridden must match between the class and subclass.
Yes, in fact this is the intention of several of the cases you listed
(all the ones in a class ending with _ImplBase).
So - user code method declarations which were overriding "built-in" methods
where the throws clause was changed, would need to change.
My hope was that we could use this "one-time" migration to clean this
up, with
possible help from the migration tool :-)
Many of the others are in our test cases and could be cleaned up if we
so choose. Other than those and the _ImplBase ones, I'm not sure
what's really left that's worth cleaning up.
In any case I'm not sure I want to attempt an automated way of
removing invalid catch blocks.
-Adam
