UnimplementedException: bad idea or not?

[mThornton@xxxxxxxxxxxx (Mark Thornton)]

The collections interfaces in java.util use this 'horrible design'.
There many methods specified as 'optional'. IMHO the collections
interfaces would have been significantly more tedious to use had this
approach not been taken.
=A0
Oh, I seem to remember that COM also has the concept of not implemented
'exceptions'.
=A0
Regards,
Mark Thornton

-----Original Message-----
From: Erik Huddleston [mailto:ehuddleston@xxxxxxxxxxxxxx]
Sent: 30 January 2000 01:52
To: 'advanced-java@xxxxxxxxxxxxxxxx'
Subject: RE: UnimplementedException: bad idea or not?



Not implemented exceptions are a horrible design.=A0 By implementing an
interface you are saying, "I support this contract!".=A0 By throwing a
runtime exception for some subset of your=A0 methods, you are breaking
that contract.=A0 I would instead refactor your design to make more
granular interfaces that you _can_ implement.=A0 And just don't =
implement
the parts you can't.=A0 Your end users can then query your component to
discover the services it offers and they can be confident that you
aren't lying to them.=A0 :-)=A0 The JavaBeans standard has some
infrastructure for handling this in a more elegant fashion than
ClassCastExceptions.=A0 And, of course, COM uses this pattern as a
fundamental tenet so you can check the COM literature as well.


Erik=20
--=20
Erik Huddleston, erikh@xxxxxxxx=20
Chief Architect, eCustomers.com=20
Microsoft Java MVP=20

> -----Original Message-----=20
> From: Chris Kelly [ mailto:samizdat@xxxxxxxxxxx]=20
> Sent: Saturday, January 29, 2000 7:18 PM=20
> To: advanced-java@xxxxxxxxxxxxxxxx=20
> Subject: UnimplementedException: bad idea or not?=20
>=20
>=20
> Is it a bad idea to throw an exception when a feature is not=20
> implemented,=20
> but the caller of the method can't tell beforehand whether=20
> that method is=20
> implemented?=20
>=20
> For the sake of argument, assume you have:=20
>=20
>=A0=A0 class UnimplementedException extends RuntimeException {=20
>=A0=A0=A0=A0 ...=20
>=A0=A0 }=20
>=20
>=A0=A0 interface Interface {=20
>=A0=A0=A0=A0 int getA();=20
>=A0=A0=A0=A0 int getB();=20
>=A0=A0 }=20
>=20
> You want to use it like this:=20
>=20
>=A0=A0 Interface i =3D getAnObjectSomePlace();=20
>=A0=A0 System.out.println( "A=3D" + i.getA() + ", B=3D" + i.getB() );=20
>=20
> And, you have two classes that implement Interface:=20
>=20
>=A0=A0 class One {=20
>=A0=A0=A0=A0 int getA() { return 1; }=20
>=A0=A0=A0=A0 int getB() { return 1; }=20
>=A0=A0 }=20
>=20
>=A0=A0 class Two {=20
>=A0=A0=A0=A0 int getA() { return 2; }=20
>=A0=A0=A0=A0 int getB() { throw new UnimplementedException(); }=20
>=A0=A0 }=20
>=20
> Is there a better way to do this, such as by returning a numeric code =

> instead of throwing an exception? You don't want to bail just because =

> something is unimplemented, you just want to ignore it.=20
>=20
> Because, the code above could become:=20
>=20
>=A0=A0 Interface i =3D getAnObjectSomePlace();=20
>=A0=A0 int=A0 A,B;=20
>=A0=A0 try {=20
>=A0=A0=A0=A0 A =3D i.getA();=20
>=A0=A0 }=20
>=A0=A0 catch ( UnimplementedException e ) {=20
>=A0=A0=A0=A0 A =3D -1;=20
>=A0=A0 }=20
>=20
>=A0=A0 try {=20
>=A0=A0=A0=A0 B =3D i.getB();=20
>=A0=A0 }=20
>=A0=A0 catch ( UnimplementedException e ) {=20
>=A0=A0=A0=A0 B =3D -1;=20
>=A0=A0 }=20
>=20
>=A0=A0 System.out.println( "A=3D" + A + ", B=3D" + B );=20
>=20
>=20
>=20
> ---=20
> To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx=20
> To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx=20
>=20


---
To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx