RE: NYIException

[Andrew Haley]

Jeroen Frijters writes:
 > Michael Koch wrote:
 > > Am Samstag, 27. September 2003 10:43 schrieb Jeroen Frijters:
 > > > Per Bothner wrote:
 > > > > >>We discussed this in March, and there was agreement that we
 > > > > >>should use use UnsupportedOperationException.
 > > > > >>
 > > > > >>See http://gcc.gnu.org/ml/java/2003-03/msg00016.html
 > > > > >
 > > > > > Its never too late to rethink something.
 > > > >
 > > > > But unless one is aware of previous discussion (and even if one
 > > > > is), much time may be wasted.  So far I haven't seen any reason
 > > > > why we need to re-consider the previous consensus.
 > > >
 > > > I just re-read the previous discussion and there Andrew Haley wrote:
 > > > > UnsupportedOperationException is a good choice.  Any subclass of
 > > > > Error is not, because according to the spec Error "indicates
 > > > > serious problems that a reasonable application should not try to
 > > > > catch."
 > > >
 > > > IMNSHO, this is *exactly* why we must define a new exception
 > > > derived from Error. An unimplemented method *is* a serious problem
 > > > that a reasonable application should not try to catch.
 > > >
 > > > So, I think it is an extremely bad idea to use
 > > > UnsupportedOperationException (or a subclass of it).
 > > 
 > > Have you misread Andrew's comment ? I read it exaclty the other way 
 > > around then you.
 > 
 > I didn't misread it, I just strongly disagree with it. If Andrew's
 > argument was the reason UnsupportedOperationException was chosen, I
 > think we need to reconsider.
 > 
 > Surely there is defensively written code out there that handles
 > UnsupportedOperationException (for example, when dealing with
 > collections), this will consume our UnsupportedOperationException
 > (which really means something quite different) and make diagnosing
 > the problem extremely hard. When an application depends on missing
 > functionality I want to see the exception and reduce the chance
 > that the app accidentally eats the exception.

My only argument was against subclassing Error, because the Java
specification strongly implies that the only reasonable thing to do
when receiving an Error is issue a disgnostic and die.  In the case of
unimplemented Classpath methods, this seems rather extreme.

Andrew.