Disambiguating empty catch blocks

[Bruce Chapman]

Thanks Martin,

comment inline.

Bruce


Martin Buchholz wrote:
> Hi Bruce,
>
> 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.  :)
> 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. 
Of course in JDK7 we'll be able to

catch (@Ignored SomeException ex) { }

catch (@Impossible SomeException ex) { }


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