Disambiguating empty catch blocks

[David Holmes]

Bruce Chapman said the following on 04/14/10 20:49:
> Martin Buchholz wrote:
>> I don't think you're going to find enough support for adding
>> rarely used new methods to existing exception classes.
>>   
> Of course it is rare at present - it doesn't yet exist. So "rarely used" 
> is at this point subjective and hypothetical. My feeling is that it 
> would be useful, if you think not, then that is another data point. 
> Maybe a weekly survey question for java.net?  - I am sure they could 
> find a way to turn it into 5 choices.  :)

I agree with Martin these methods are unnecessary and would be rarely 
used if they existed. That's subjective of course but all library design 
involves some considered subjectivity about likelihood of use.

>> There's already a clear way to indicate to human readers
>> that an exception should be ignored or is expected
>>
>> catch (SomeException ignored) { }
>>
>> catch (SomeException expected) { }
>>   
> 
> Oh dear, I thought we had finally got away from "magic name" solutions. 

I don't see anything wrong with this. On the other hand I find it 
completely <insert strong adjective> to signify you are ignoring an 
exception by calling an ignore() method that does nothing. This isn't a 
coding issue it is a documentation issue - what is the intent? Why is 
the occurrence of the exception of no consequence? Using:

catch (SomeException ignore) { }

is fine though perhaps a little obscure; using

catch (SomeException ignore { /* reason we can ignore*/ }

is better. Using:

catch (SomeException e) { e.ignore(); }

is just pointless and just as obscure.

> Of course in JDK7 we'll be able to
> 
> catch (@Ignored SomeException ex) { }
> 
> catch (@Impossible SomeException ex) { }

Annotations are overkill for this.

As for "impossible":

throw new Error("can't happen");

Seems fine to me.

My 2c.

David Holmes

> and maybe that is an OK option. However getting those annotations added 
> to the JDK is probably less likely than a couple of methods on Exception.
> Also the @Impossible (or a magic variable name) can't throw an 
> AssertionError without a language change and is therefore significantly 
> inferior to an impossible() method.
>> All we need for true happiness is for all linty tools to
>> buy into this convention and to advertise it as the
>> One True Way to ignore exceptions.
>>   
> ahhh Nirvana, but we can't MAKE that happen - but we can add methods (or 
> annotations) to the JDK.
>> One thing we definitely can do is to add a new constructor
>> to AssertionError, that takes a cause as an argument,
>> consistent with other exceptions.
>>   
> Yeah, that was a minor niggle - I'll check  for an RFE and get the ball 
> started on that.
>> There is a bit of a religious argument as to whether
>> AssertionError should only be thrown by an assert statement.
>> Is there a better Error to throw? Hmmmm...checking the JDK sources, it 
>> seems that
>> AssertionError is the defacto standard.
>> I will sponsor a patch to add the new constructor to AssertionError,
>> which will at least make the boilerplate for throwing an
>> impossible error smaller.
>>   
> I guess if it had been the intention to only throw those from asserts, 
> then the constructor could have been private to stop other uses, and let 
> the language and compiler do some magic to let it be so, but that didn't 
> happen.
> 
> Thanks
> 
> Bruce
>