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@cs.vu.nl> To: mathijs@cs.vu.nl CC: Thilo Kielmann <kielmann@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.