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
