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