[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NYIException
From: |
Andrew Haley |
Subject: |
Re: NYIException |
Date: |
Mon, 29 Sep 2003 19:25:36 +0100 |
Andy Walter writes:
> Hi Andrew,
>
> On Monday 29 September 2003 19:40, Andrew Haley wrote:
> > Throwing an appropriate message will help, of course, but one of
> > the advantages of gcj is that you can pre-link and you know you
> > won't get runtime linkage errors -- the linker has resolved
> > everything. Having dummy implementations loses this gcj
> > advantage.
>
> Dummy implementations that do nothing are a really bad thing, I
> agree. But a dummy implementation that either returns with the
> correct result or throws a NYIException makes it clear to the user
> what had happened.
>
> Currently, we have those dummy methods anyway - and can't get rid
> of them, because some methods are partly, but not completely,
> implemented. With a new Exception class, the gcj linker could stop
> with an error message when such a method is instantiated and
> thrown.
Err, no. Linking happens at link time; throwing happens at runtime!
But this gives me an idea. I can parse the class at compile time, and
if I see any references to a method that throws such an exception I
can warn the user about it. That would be *much* better. It wouldn't
be complete because there might be partly implemented subclasses that
aren't directly referenced, but it would be better than nothing.
> If we abuse any existing JDK Exeption for it, this would not be
> possible.
True.
Andrew.
- Re: NYIException, (continued)
Re: NYIException, Per Bothner, 2003/09/29
RE: NYIException, Jeroen Frijters, 2003/09/29