Unreachable catch classes
David Holmes
David.Holmes at oracle.com
Thu May 26 02:27:46 UTC 2011
It hadn't occurred to me before but the "more precise rethrow" semantics
are basically making the same invalid assumption about where checked
exceptions can be thrown. Before if you catch Throwable and want to
rethrow then you have to cast to an unchecked exception type, or else
wrap with an unchecked exception type. Now you can catch Throwable and
simply rethrow it - potentially letting an undeclared checked-exception
to continue to make its escape.
Now given that you could instead have only caught unchecked-exceptions,
and the undeclared checked exception would have escaped anyway, this is
perhaps not a big deal.
But it troubles me that the language assumes things that are known to
not be upheld by the libraries, and rather than helping to identify such
cases this language change will now be helping to hide such cases.
David
David Holmes said the following on 04/28/11 22:03:
> Maurizio Cimadamore said the following on 04/28/11 21:56:
>> On 27/04/11 13:51, Maurizio Cimadamore wrote:
>>> On 27/04/11 09:18, David Holmes wrote:
>>>> Special-casing Throwable wouldn't be sufficient as people may use
>>>> Exception instead.
>>> I guess this doesn't invalidate the argument - we could special-case
>>> Exception AND Throwable, since they are already treated specially in
>>> the language...
>>>
>>> Maurizio
>> Hi
>> after a discussion with the team, we have decided that we will relax
>> the new javac warnings so that they will *not* be generated for those
>> catch clauses catching Exception or Throwable.
>>
>> This is similar to how javac has always handled a similar case (error
>> message: 'exception never thrown in body of try'); for example, this
>> code compiles:
>>
>> try { }
>> catch (Exception e) { ... }
>>
>> while the following does not compile:
>>
>> try { }
>> catch (IOException e) { ... } //error IOException never thrown
>
> Thanks Maurizio. I never realized the above case existed. :)
>
> David
> -----
>
>
>>
>> The code generating the newly added javac warnings will be changed
>> accordingly; for example, the following will compile w/o warnings:
>>
>> try { throw new FileNotFoundException(); }
>> catch (FileNotFoundException fnf) { ... }
>> catch (Exception e) { ... }
>>
>> while the following code will still emit a 'dead catch' warning:
>>
>> try { throw new FileNotFoundException(); }
>> catch (FileNotFoundException fnf) { ... }
>> catch (IOException e) { ... }
>>
>>
>> This should accommodate all weird cases of checked exceptions not
>> being declared (as in Class.newInstance).
>>
>> Maurizio
>>
>>
>>
>>
>>
More information about the core-libs-dev
mailing list