[SAGA-RG] Java SAGA and NotImplementedExceptions in URL

Ceriel Jacobs ceriel at cs.vu.nl
Mon Sep 8 01:52:43 CDT 2008


Hi Andre,

thanks for your elaborate answer. I think the conclusion for us is that
the in the Java bindings, the URL methods will no longer throw NotImplemented,
but the URL factory method can still throw it. This obligates an implementation
to either implement URL completely or not at all.

Comments, anyone?

Ceriel


Andre Merzky wrote:
> 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 at cs.vu.nl>
>>> To: mathijs at cs.vu.nl
>>> CC: Thilo Kielmann <kielmann at 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



More information about the saga-rg mailing list