This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: unimplemented methods
- From: Andrew Haley <aph at redhat dot com>
- To: Øyvind Harboe <oyvind dot harboe at zylin dot com>
- Cc: "Per Bothner" <per at bothner dot com>, <java at gcc dot gnu dot org>
- Date: Sun, 2 Mar 2003 12:15:30 +0000 (GMT)
- Subject: RE: unimplemented methods
- References: <41D1051F31A2674C99E41CA28EE734980A1FAE@isp-ex2k.intellimade.net>
=?iso-8859-1?Q?=D8yvind=5FHarboe?= writes:
> > This has to stop. If an method does not do what it
> > is supposed to do, then it must throw an exception.
>
> I think this is generally a good idea. My first encounter
> with this sort of thing was Thread.interrupt(), which is
> a C++ method, though I assume the same rules apply.
>
> Perhaps the behaviour of unimplemented methods could be
> made run-time configurable?
I am strongly opposed to this idea. We have enough bloat as it is:
it's not really our fault, but I don't want any more.
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."
Andrew.