Multi-catch: Explanation of final

[Paul Benedict]

Wouldn't this be an acceptable conclusion to lifting the final variable?

catch(IOException|SQLException ex) {
   ex = new IllegalArgumentException(); // error since ex is not one
of the disjunctive supertypes
   ex = new IOException(); // ok
   ex = new SQLException(); // ok
}

Paul

On Tue, Nov 24, 2009 at 8:45 PM, Neal Gafter <neal at gafter.com> wrote:
> On Tue, Nov 24, 2009 at 5:48 PM, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
>>
>> Paul Benedict wrote:
>> > I have some difficulty understanding why "final" is necessary in the
>> > multi-catch proposal. Can anyone help me understand better? I know it
>> > revolves around limiting the scope of disjunctive types, but it's not
>> > clear to me.
>> >
>>
>> "final" tells the compiler the catch variable does not change; therefore
>> if the value of variable is rethrown, the compiler knows that the set of
>> exceptions throwable by the rethrow is exactly the same as the exception
>> that could be caught by that block.
>
> Right.  To expand on that, if it were not final in a
>
> catch (IOException|SQLException ex)
>
> the type of ex inside the block would be Exception (their common
> supertype).  So you could assign an InstantiationException to ex and then
> rethrow it.  To preserve type safety, then, throwing ex must be considered
> the same as throwing Exception.  By requiring ex be final, throwing ex can
> only possibly rethrow the exceptions that the catch clause can catch, which
> include only IOException and SQLException (two catch table entries are
> generated for this catch clause).
>
> However, if support for exception transparency (disjunctive types) is added
> for closures, then the final requirement could be lifted.
>
> Cheers,
> Neal
>