Re: Eclipse 3.0

[Andrew John Hughes]

On Fri, 2004-07-02 at 12:00, Roman Kennke wrote:
> Am Fr, den 02.07.2004 schrieb Andrew John Hughes um 12:49:
> > On Fri, 2004-07-02 at 11:31, Roman Kennke wrote:
> > > > Caused by: java.lang.NullPointerException
> > > >    at 
> > > > org.eclipse.osgi.framework.adaptor.core.BundleResourceHandler.openConnection
> > > >  (BundleResourceHandler.java:138)
> > > >    at java.net.URL.openConnection (URL.java:658)
> > > >    at java.net.URL.openStream (URL.java:671)
> > > >    at 
> > > > org.eclipse.osgi.framework.internal.core.ManifestLocalization.getResourceBundle
> > > >  (ManifestLocalization.java:114)
> > > > [...]
> > > > 
> > > > This indicates that it is a general bug in our GNU Classpath core
> > > > libraries. I have been unable to pinpoint it however.
> > > 
> > > just an observation: NullPointerExceptions are often thrown, because in
> > > GNU Classpath are lots of method skeletons, which are not yet
> > > implemented and only return null. Maybe (hopefully) this is such a
> > > case.? Didn't look at it though.
> > > 
> > > Maybe we should go and throw out (or even better: implement) any such
> > > methods. Then we would see such problems earlier -- during compiling.
> > > Although, this would very likely break alot of things.
> 
> > Yes, I have to concur here -- I don't think we should have
> > implementations that need completing but are hidden by returning null,
> > even if it means some things break.  Throwing an Error would be much
> > clearer, and make it obvious where holes in the implementation exist. 
> > Things like this make it appear that we have support that we don't -- I
> > think a lot of the newer APIs are hidden in this way.
> 
> for the 0.10 release we could and should throw out any such methods if
> it ain't break anything, and those, which would break compilation should
> either be implemented (best solution) or should throw a
> NotImplementedException, which tells exactly, WHAT and WHERE something
> is not implemented (and maybe WHY ;).
> 
> Do you think, that makes sense? Or is this too much effort? Could
> finding such methods be automated?
> 
> /Roman
> 
> 
> ______________________________________________________________________
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath

Sounds good to me.  I wouldn't actually throw out any methods, simply
because eventually someone will have to put it back in and that's just
more time -- there's usually also a good reason a method hook has been
put in, I imagine.  I can see the situation where someone would be
implementing something, find they need to support an optional method
somewhere else and put an empty hook in.  I just really needs to be the
policy to have these hooks as throwing Errors rather than simply sending
back nulls (which in a lot of cases is a valid result -- so the calling
code expects it and takes an appropriate codepath, not knowing that the
actual result is an error).  I'm more for an Error throw rather than an
Exception, simply because bad calling code may just swallow exceptions. 
I don't think any of it will expect NotImplemented, and we need
something that will unavoidably spit out the result of calling a dead
method.  I may be barking up the wrong tree here -- if NotImplemented
allows this behaviour by descending from an appropriate superclass, then
by all means use this.  But I think the very thing we want to avoid is
silent handling of these hooks, whether it be by null or an exception
being swallowed by catch (Exception e) {} (and yes people do this...).

Breaking parts of Classpath that 'work' doesn't sound like a thrilling
prospect, but its something that needs to be done if we are going to get
to an acceptable implementation. Mark's problems with Eclipse just show
the problems that occur when you have to find errors in two large
codebases, and Classpath is swallowing the error that would give the
game away. 
-- 
Andrew :-)
 
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
 
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.

signature.asc
Description: This is a digitally signed message part