UnimplementedException: bad idea or not?

[mThornton@xxxxxxxxxxxx (Mark Thornton)]

The only problem I can see is where an implementation wishes to support
some but not all of the modification methods. Otherwise I agree that the
paired interfaces would have been a better design.
Of course that ModifiableListIterator would extend both ListIterator and
ModifiableIterator (and similarly ModifiableSortedMap extends SortedMap
and ModifiableMap).

The only real objection is the need for casting which would be
eliminated by allowing covariant return types (assuming that applies to
subinterfaces as well as sub classes).

Regards,
Mark Thornton

-----Original Message-----
From: Dennis Sosnoski [mailto:dms@xxxxxxxxxxxx]
Sent: 30 January 2000 18:05
To: Mark Thornton
Cc: Erik Huddleston; 'advanced-java@xxxxxxxxxxxxxxxx'
Subject: Re: UnimplementedException: bad idea or not?


I've felt the exception throwing by the collections interfaces was ugly
from the
first time I saw it, and still do. At a glance it seems like it would
have been
easy to just do paired sets of interfaces, with the mutable one
extending the
one which had no modification methods exposed. Do you see some problem
with this
approach, Mark?

It would provide a clean set of interfaces where everything was
explicit. The
only problem I can see with this is that, because of the design error in
Java
which prevents refining the return type of a method in a subclass (see
bug
4144488, classified by Sun as an enhancement request, at
http://developer.java.sun.com/developer/bugParade/bugs/4144488.html),
you
wouldn't be able to return a ModifiableListIterator where appropriate
rather
than a plain ListIterator with no support for modifications. Still, this
could
be handled by casting until they get the language problem fixed.

  - Dennis

Dennis M. Sosnoski
Sosnoski Software Solutions, Inc.
http://www.sosnoski.com

Mark Thornton wrote:
> 
> 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.
> 
> Oh, I seem to remember that COM also has the concept of not
implemented
> 'exceptions'.
> 
> 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.  By implementing an
> interface you are saying, "I support this contract!".  By throwing a
> runtime exception for some subset of your  methods, you are breaking
> that contract.  I would instead refactor your design to make more
> granular interfaces that you _can_ implement.  And just don't
implement
> the parts you can't.  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.  :-)  The JavaBeans standard has some
> infrastructure for handling this in a more elegant fashion than
> ClassCastExceptions.  And, of course, COM uses this pattern as a
> fundamental tenet so you can check the COM literature as well.
> 
> Erik
> --
> Erik Huddleston, erikh@xxxxxxxx
> Chief Architect, eCustomers.com
> Microsoft Java MVP
> 
> > -----Original Message-----
> > From: Chris Kelly [ mailto:samizdat@xxxxxxxxxxx]
> > Sent: Saturday, January 29, 2000 7:18 PM
> > To: advanced-java@xxxxxxxxxxxxxxxx
> > Subject: UnimplementedException: bad idea or not?
> >
> >
> > Is it a bad idea to throw an exception when a feature is not
> > implemented,
> > but the caller of the method can't tell beforehand whether
> > that method is
> > implemented?
> >
> > For the sake of argument, assume you have:
> >
> >   class UnimplementedException extends RuntimeException {
> >     ...
> >   }
> >
> >   interface Interface {
> >     int getA();
> >     int getB();
> >   }
> >
> > You want to use it like this:
> >
> >   Interface i = getAnObjectSomePlace();
> >   System.out.println( "A=" + i.getA() + ", B=" + i.getB() );
> >
> > And, you have two classes that implement Interface:
> >
> >   class One {
> >     int getA() { return 1; }
> >     int getB() { return 1; }
> >   }
> >
> >   class Two {
> >     int getA() { return 2; }
> >     int getB() { throw new UnimplementedException(); }
> >   }
> >
> > 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.
> >
> > Because, the code above could become:
> >
> >   Interface i = getAnObjectSomePlace();
> >   int  A,B;
> >   try {
> >     A = i.getA();
> >   }
> >   catch ( UnimplementedException e ) {
> >     A = -1;
> >   }
> >
> >   try {
> >     B = i.getB();
> >   }
> >   catch ( UnimplementedException e ) {
> >     B = -1;
> >   }
> >
> >   System.out.println( "A=" + A + ", B=" + B );
> >
> >
> >
> > ---
> > To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
> > To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx
> >
> 
> ---
> To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
> To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx

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

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