Search the archives!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
UnimplementedException: bad idea or not?
- From: ehuddleston@xxxxxxxxxxxxxx (Erik Huddleston)
- Subject: UnimplementedException: bad idea or not?
- Date: Sun, 30 Jan 2000 10:46:12 -0600
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6B41.846A7EA2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable E_NOTIMPL (the HRESULT for this design) originated from automation. In automation, there is only one interface, IDispatch. Therefore, the = design I am advocating would be rather hard to implement, agreed? :-) This was not meant as a flame, just meant to point out that your = example is not applicable. (and yes people who use this in COM outside of = automation (Microsoft has been guilty of it on occasion.) are damned to hell as = well. :-) ). But seriously, sometimes you have to do what you have to do (David had = some good advice on that point). However, when you have the time and the = choice, using patterns where the object contract is explicit and honored is = almost always best. Erik -- Erik Huddleston, erikh@xxxxxxxx Chief Architect, eCustomers.com Microsoft Java MVP=20 > -----Original Message----- > From: Mark Thornton [mailto:mThornton@xxxxxxxxxxxx] > Sent: Sunday, January 30, 2000 9:03 AM > To: Erik Huddleston; 'advanced-java@xxxxxxxxxxxxxxxx' > Subject: RE: UnimplementedException: bad idea or not? >=20 >=20 > 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=20 > implemented > 'exceptions'. > =A0 > Regards, > Mark Thornton >=20 > -----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? >=20 >=20 >=20 > 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=20 > 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. >=20 >=20 > Erik=20 > --=20 > Erik Huddleston, erikh@xxxxxxxx=20 > Chief Architect, eCustomers.com=20 > Microsoft Java MVP=20 >=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=20 > numeric code=20 > > instead of throwing an exception? You don't want to bail=20 > just because=20 > > 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 >=20 >=20 > --- > To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx > To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx >=20 ------_=_NextPart_001_01BF6B41.846A7EA2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2650.12"> <TITLE>RE: UnimplementedException: bad idea or not?</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>E_NOTIMPL (the HRESULT for this design) originated = from automation. In automation, there is only one interface, = IDispatch. Therefore, the design I am advocating would be rather = hard to implement, agreed? :-)</FONT></P> <P><FONT SIZE=3D2>This was not meant as a flame, just meant to point = out that your example is not applicable. (and yes people who use this = in COM outside of automation (Microsoft has been guilty of it on = occasion.) are damned to hell as well. :-) ).</FONT></P> <P><FONT SIZE=3D2>But seriously, sometimes you have to do what you have = to do (David had some good advice on that point). However, when = you have the time and the choice, using patterns where the object = contract is explicit and honored is almost always best.</FONT></P> <BR> <P><FONT SIZE=3D2>Erik</FONT> <BR><FONT SIZE=3D2>--</FONT> <BR><FONT SIZE=3D2>Erik Huddleston, erikh@xxxxxxxx</FONT> <BR><FONT SIZE=3D2>Chief Architect, eCustomers.com</FONT> <BR><FONT SIZE=3D2>Microsoft Java MVP </FONT> </P> <P><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: Mark Thornton [<A = HREF=3D"mailto:mThornton@xxxxxxxxxxxx";>mailto:mThornton@xxxxxxxxxxxx</A>= ]</FONT> <BR><FONT SIZE=3D2>> Sent: Sunday, January 30, 2000 9:03 AM</FONT> <BR><FONT SIZE=3D2>> To: Erik Huddleston; = 'advanced-java@xxxxxxxxxxxxxxxx'</FONT> <BR><FONT SIZE=3D2>> Subject: RE: UnimplementedException: bad idea = or not?</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> The collections interfaces in java.util use = this 'horrible design'.</FONT> <BR><FONT SIZE=3D2>> There many methods specified as 'optional'. = IMHO the collections</FONT> <BR><FONT SIZE=3D2>> interfaces would have been significantly more = tedious to use had this</FONT> <BR><FONT SIZE=3D2>> approach not been taken.</FONT> <BR><FONT SIZE=3D2>> =A0</FONT> <BR><FONT SIZE=3D2>> Oh, I seem to remember that COM also has the = concept of not </FONT> <BR><FONT SIZE=3D2>> implemented</FONT> <BR><FONT SIZE=3D2>> 'exceptions'.</FONT> <BR><FONT SIZE=3D2>> =A0</FONT> <BR><FONT SIZE=3D2>> Regards,</FONT> <BR><FONT SIZE=3D2>> Mark Thornton</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: Erik Huddleston [<A = HREF=3D"mailto:ehuddleston@xxxxxxxxxxxxxx";>mailto:ehuddleston@ecustomers= .com</A>]</FONT> <BR><FONT SIZE=3D2>> Sent: 30 January 2000 01:52</FONT> <BR><FONT SIZE=3D2>> To: 'advanced-java@xxxxxxxxxxxxxxxx'</FONT> <BR><FONT SIZE=3D2>> Subject: RE: UnimplementedException: bad idea = or not?</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Not implemented exceptions are a horrible = design.=A0 By implementing an</FONT> <BR><FONT SIZE=3D2>> interface you are saying, "I support this = contract!".=A0 By throwing a</FONT> <BR><FONT SIZE=3D2>> runtime exception for some subset of your=A0 = methods, you are breaking</FONT> <BR><FONT SIZE=3D2>> that contract.=A0 I would instead refactor your = design to make more</FONT> <BR><FONT SIZE=3D2>> granular interfaces that you _can_ = implement.=A0 And just don't </FONT> <BR><FONT SIZE=3D2>> implement</FONT> <BR><FONT SIZE=3D2>> the parts you can't.=A0 Your end users can then = query your component to</FONT> <BR><FONT SIZE=3D2>> discover the services it offers and they can be = confident that you</FONT> <BR><FONT SIZE=3D2>> aren't lying to them.=A0 :-)=A0 The JavaBeans = standard has some</FONT> <BR><FONT SIZE=3D2>> infrastructure for handling this in a more = elegant fashion than</FONT> <BR><FONT SIZE=3D2>> ClassCastExceptions.=A0 And, of course, COM = uses this pattern as a</FONT> <BR><FONT SIZE=3D2>> fundamental tenet so you can check the COM = literature as well.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Erik </FONT> <BR><FONT SIZE=3D2>> -- </FONT> <BR><FONT SIZE=3D2>> Erik Huddleston, erikh@xxxxxxxx </FONT> <BR><FONT SIZE=3D2>> Chief Architect, eCustomers.com </FONT> <BR><FONT SIZE=3D2>> Microsoft Java MVP </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> > -----Original Message----- </FONT> <BR><FONT SIZE=3D2>> > From: Chris Kelly [ <A = HREF=3D"mailto:samizdat@xxxxxxxxxxx";>mailto:samizdat@xxxxxxxxxxx</A>] = </FONT> <BR><FONT SIZE=3D2>> > Sent: Saturday, January 29, 2000 7:18 PM = </FONT> <BR><FONT SIZE=3D2>> > To: advanced-java@xxxxxxxxxxxxxxxx </FONT> <BR><FONT SIZE=3D2>> > Subject: UnimplementedException: bad idea = or not? </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > Is it a bad idea to throw an exception = when a feature is not </FONT> <BR><FONT SIZE=3D2>> > implemented, </FONT> <BR><FONT SIZE=3D2>> > but the caller of the method can't tell = beforehand whether </FONT> <BR><FONT SIZE=3D2>> > that method is </FONT> <BR><FONT SIZE=3D2>> > implemented? </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > For the sake of argument, assume you have: = </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 class UnimplementedException extends = RuntimeException { </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 ... </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 } </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 interface Interface { </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 int getA(); </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 int getB(); </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 } </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > You want to use it like this: </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 Interface i =3D = getAnObjectSomePlace(); </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 System.out.println( "A=3D" = + i.getA() + ", B=3D" + i.getB() ); </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > And, you have two classes that implement = Interface: </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 class One { </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 int getA() { return 1; } = </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 int getB() { return 1; } = </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 } </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 class Two { </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 int getA() { return 2; } = </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 int getB() { throw new = UnimplementedException(); } </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 } </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > Is there a better way to do this, such as = by returning a </FONT> <BR><FONT SIZE=3D2>> numeric code </FONT> <BR><FONT SIZE=3D2>> > instead of throwing an exception? You = don't want to bail </FONT> <BR><FONT SIZE=3D2>> just because </FONT> <BR><FONT SIZE=3D2>> > something is unimplemented, you just want = to ignore it. </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > Because, the code above could become: = </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 Interface i =3D = getAnObjectSomePlace(); </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 int=A0 A,B; </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 try { </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 A =3D i.getA(); </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 } </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 catch ( UnimplementedException e ) { = </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 A =3D -1; </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 } </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 try { </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 B =3D i.getB(); </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 } </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 catch ( UnimplementedException e ) { = </FONT> <BR><FONT SIZE=3D2>> >=A0=A0=A0=A0 B =3D -1; </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 } </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> >=A0=A0 System.out.println( "A=3D" = + A + ", B=3D" + B ); </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> > --- </FONT> <BR><FONT SIZE=3D2>> > To unsubscribe, mail = advanced-java-unsubscribe@xxxxxxxxxxxxxxxx </FONT> <BR><FONT SIZE=3D2>> > To get help, mail = advanced-java-help@xxxxxxxxxxxxxxxx </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> ---</FONT> <BR><FONT SIZE=3D2>> To unsubscribe, mail = advanced-java-unsubscribe@xxxxxxxxxxxxxxxx</FONT> <BR><FONT SIZE=3D2>> To get help, mail = advanced-java-help@xxxxxxxxxxxxxxxx</FONT> <BR><FONT SIZE=3D2>> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01BF6B41.846A7EA2-- --- To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx
- Follow-Ups:
- JDBC
- From: Matthias Carlsson
- JDBC
- Prev by Date: Pls. suggest a free Java Editor / IDE for Win 95/NT
- Next by Date: swing.jar or swingall.jar
- Previous by thread: UnimplementedException: bad idea or not?
- Next by thread: JDBC
- Index(es):