RE: Unwanted (?) exceptions in DDR Simple API spec

Actually, given that the specification does not explicitly bind, derive
or inherit from an particular exception class in Java, if one sticks
purely to catching DDRException while making no assumption about its
ancestry, then I see no reason why a particular implementation shouldn't
attach DDRException to any arbitrary part of its package hierarchy.
Conformance refers only to those parts explicitly called out in the
specification, and while the Java language was used as a means of
expression, the specification does not depend on the whole Java
environment, libraries and other knobs and dials that come with it.

The only normative requirement in the specification is that the
exception class named DDRException provides two methods called getCode()
and getMessage() returning an integer and string respectively. No more,
no less.

Obviously any conforming implementation would include documentation
explaining how the implementation co-exists with its programming
environment, whether it be in Java, Python, C++ or whatever. I think
that if Jo decides to offer an implementation that has DDRException
(from the DDR API) subclassing SystemException (from the standard Java
packages) then fair enough. I know he'll document it carefully, in case
anyone starts making contrary assumptions based on the original
illustrative Java implementation that accompanied the specification.
(It's possible that some people may have already made such assumptions,
but nobody's perfect.)

---Rotan

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Jo Rabin
Sent: 25 November 2009 15:06
To: public-ddwg@w3.org
Subject: Unwanted (?) exceptions in DDR Simple API spec

Dear Survivor of the DDWG (as Francois put it :-) )

A question I've been meaning to put to colleagues is ref the 
specification of Exceptions in the API. I've been working with a Java 
implementation for some time now and frequently end up with something 
like this:

try {
    pvv = service.getPropertyValues(evidence);
} catch (NameException e1) {
    // can't get here
    e1.printStackTrace();
}

for (PropertyValue pv: pvv.getAll()) {
    try {
       System.out.println(pv.getString());
    } catch (ValueException e) {
       // can't get here
       e.printStackTrace();
    }
}

It seems to me that there is a strong case for changing the exception 
types to avoid this unnecessary round the houses. Interestingly enough, 
though DDRException subclasses Exception in the supplied Java, it is not

stated explicitly in the API documentation that this is the case. Would 
it be acceptable for a conforming implementation to have DDRException 
subclass SystemException, I wonder?

thanks
Jo

Received on Wednesday, 25 November 2009 16:11:05 UTC