Re: NotYetImplementedError [Was: NYIException]

[Etienne Gagnon]

Stephen,

Do as you like.  I do not want to fight on this.  I think that my
proposal is the best approach to (1) handle missing functionality in a
way that will make life easier to users trying to run Java
applications on classpath-based free vms amd (2) mimick the
LinkageError usually expected in case of *unexpected* missing
functionality (in contrast with *expected* missing functionality,
indicated by UnsupportedOperationExcaprion).  You seem to hold on your
vision very strongly, and I am not ready to spend the effort to
convince you.

Etienne


On Mon, Sep 29, 2003 at 02:32:49PM +1000, Stephen Crawley wrote:
> > Stephen Crawley wrote:
> > > If no user is allowed to catch this new error/exception, why are we going
> > > to the bother of creating it in the first place??
> > 
> > So that, when a user runs his application on top of a Free jvm using 
> > Classpath, he can identify clearly missing functionality (at run time, 
> > at least).
> 
> This is equally satisfied by throwing UnsupportedOperationException
> with a stereotypical message; e.g.
> 
>   throw new UnsupportedOperationException("not implemented yet - <details>")
> 
> > > If the only reason for creating the new exception is as a documentation 
> > > aid, then a better approach would be to throw 
> > > UnsupportedOperationException
> > > with a stereotypical error message and or stereotypical javadoc 
> > > description.
> > 
> > No, because UnsupportedOperationException carries different semantics: 
> > it implies that the application was expecting some operation could be 
> > missing (as is the case with collections).
> 
> I cannot see for the life of me where you are got this "different
> semantics" idea from.  The documentation for the exception defines its
> semantics as:
> 
>   "Thrown to indicate that the requested operation is not supported."
> 
> That is it.  
> 
> Our usage would be entirely consistent with this.  An unimplemented
> operation is (by definition) not supported because it is not implemented
> yet!!  Even the Collections Framework javadocs say (typically) that the
> exception is thrown because (e.g.) "xyz is not supported by this
> collection" without necessarily saying why.
> 
> > See in my other message the example with JDK versions leading to 
> > LinkageError (not LinkageException extends UnsupportedOperationException).
> 
> What is happening here is that you are calling a method that does not
> exist in the older JDK. 
> 
> If we want this effect, we should NOT provide skeleton implementations
> for missing methods at all.  This would give a compilation error when
> the application is compiled against Classpath, and a LinkageError if the
> end user ran it the Classpath platform.
> 
> (Not that I think this would be a good idea ... )
> 
> > > I think it is unreasonable to expect application developers to know
> > > which features where unimplemented / implemented in which versions
> > > of Classpath.  IMO, this far more awkward than catching an exception.
> > 
> > Not at all.  A normal Java programmer should expect nothing.  He should 
> > simply try to run his application, and if a NYIE happens, he should try 
> > to either:
> > (1) implement the missing functionality (and contribute to classpath)
> > (2) try to circumvent the missing functionality by using equivalent, but 
> > implemented, classes/methods.
> 
> Huh?  A moment ago you were suggesting that the application programmer
> should use properties containing Classpath version numbers and god-like 
> awareness of which versions of Classpath implemented which methods.
> You were saying that this was easier to do than catching a NYIE.  My
> comment was addressing this.
> 
> Now you seem to be saying (?) that the application programmer shouldn't
> be writing his application to be aware of missing functionality at all??
> Fine ... but then you've taken my remarks out of context. 
> 
> -- Steve
> 
> 
> 
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/