Hi guys,
Quoting [Thilo Kielmann] (Sep 05 2008):
>
> I suggest to ask the experts:
>
> Andre, why does SAGA, "the language independent spec" :-)
> prescribe this exception?
Well, rhetorical answer is: because it may be not
implemented! Doh! :-P
> The question is: who is right:
> - SAGA from GFD.90, and the still to be published Java binding ?
> - the C++ implementation (with its ad-hoc binding) ?
If in doubt (as here): the spec.
> What would make sense?
Tough call, really.
Several ways to argument here:
1: One could argue that all Look-and-Feel classes must be
present in a SAGA implementation, so we don't need
NotImplemented. But, for example, why should a SAGA
implementation provide a saga::buffer implementation,
if it does not provide the file or stream package?
(see paragraph 6 on page 17, statement about partially
compliant implementations).
Well, sure, URL is basically used in all packages, but
we cannot be sure of that for future extensions. Thus,
an implementation may actualy decide to not implement
URL, so all \LF classes need NotImplemented.
2: If a class is not implemented, it may be enough to
require the NotImplemented exception on the ctor only,
and on method calls which are optional. But we do
not have a notion of optional methods, and such notion
would further complicate the spec, and the notion of
implementation compliance. So, all methods need
NotImplemented.
3: For OO languages, if a class is not implemented, a c'tor
would simply not be available. No need for a
NotImplemented exception on c'tors then. Also, for some
classes (like URL), all methods are usually available if
the class is available. Thus, no need for NotImplemented
on the methods either, in this case. But that line of
argument breaks for non-OO languages, where the ctor
needs the exception, and the methods need it, too.
I guess you can only get rid of the exception if you go the
language binding route (3), and argue that in Java, if URL
is implemented, all URL methods will always be implemented,
and thus the exception is not needed. Fine with me. May
make sense for C++, too, btw.
Best, Andre.
PS: Sorry for such a long winded answer to a trivial
looking problem - its just a way to say that I was
unsure what to say ;-)
> Putting the removal of this exception into the errata file sounds like a
> (lame) way of resolving this. Would this make sense at all???
>
>
> Thilo
>
> On Fri, Sep 05, 2008 at 03:50:55PM +0200, Ceriel Jacobs wrote:
> > From: Ceriel Jacobs <ceriel(a)cs.vu.nl>
> > To: mathijs(a)cs.vu.nl
> > CC: Thilo Kielmann <kielmann(a)cs.vu.nl>
> > Subject: Re: Java SAGA and NotImplementedExceptions in URL
> >
> > Mathijs den Burger wrote:
> > >Hi,
> > >
> > >While coding a file adaptor for the Java SAGA implementation, I keep
> > >getting annoyed by the fact that every setter and getter method in the
> > >URL class can throw a NotImplementedException. As a result, every method
> > >that retrieves something from a URL (a host, port, etc.) or uses such a
> > >method somewhere has to add a 'throws NotImplementedException' in its
> > >declaration. Catching these exceptions is of course possible, but it is
> > >a bit vague how to handle them ("OK, I cannot read a host name from a
> > >URL, hmm, now what?"). The simple alternative is to have many methods
> > >that throw a NotImplementedException, which bloats your code.
> >
> > It is a bit cumbersome, I agree, but the SAGA document specifies the
> > methods like this. I don't know why this is so.
> >
> > >The C++ implementations simply cheats by not throwing these exceptions
> > >from the URL class at all (an advantage of not having a proper language
> > >binding). Can't we do the same in the Java language binding? I cannot
> > >imagine a Java SAGA implementation that cannot do url.getHost() or
> > >url.getPort()...
> >
> > I would be happy to change this. Thilo, what do you think?
> >
> > Ceriel
--
Nothing is ever easy.
