Unwanted (?) exceptions in DDR Simple API spec

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Unwanted (?) exceptions in DDR Simple API spec

Jo Rabin-2
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





Reply | Threaded
Open this post in threaded view
|

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

Rotan Hanrahan
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: [hidden email] [mailto:[hidden email]] On
Behalf Of Jo Rabin
Sent: 25 November 2009 15:06
To: [hidden email]
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






Reply | Threaded
Open this post in threaded view
|

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

JOSE MANUEL CANTERA FONSECA
In reply to this post by Jo Rabin-2
Hi Jo,

although it can be possible I would not recommend it for the sake of robustness of the code, imagine for instance  a situation in which the names of the properties are obtained dynamically (for example from a file) and you end up having the name of a property which does not exist. If you don't capture exceptions explicitly your program will end unexpectedly and won't be able to recover from a simple error

So I would not take advantage of holes in the spec to satisfy certain use cases and leave the door open to break other situations Actually the majority of exceptions in Java APIs are regular exceptions that have to be captured explicitly

Best Regards


-----Mensaje original-----
De: [hidden email] [mailto:[hidden email]] En nombre de Jo Rabin
Enviado el: miércoles, 25 de noviembre de 2009 16:06
Para: [hidden email]
Asunto: 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





Reply | Threaded
Open this post in threaded view
|

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

Rotan Hanrahan
I would not characterize the absence of a specific binding to a Java exception class as a "hole in the spec". Java was chosen as the language of specification because it was widely understood and sufficiently expressive. The rest of the Java ecosystem (including the libraries, JEE etc) were not a factor. Indeed, translation to alternative languages was also high on the list of requirements, so dependencies on features beyond the raw Java language would be ill-advised.

The specification explicitly defines an exception class, and it is up to the implementer to ensure that this exception class is used in a reasonable fashion within the specific environment of the implementation. In the case of Java, there are several options to consider, including whether/how to inherit from existing exception classes (which are not mentioned in the specification).

The *safest* course of action is to inherit from Exception as per the example Java code that accompanies the specification. The motivation for this course is along the lines suggested by José.

But: there are other ways to provide safety, such as provable preconditions. If your code is designed so that by the time you reach the place where you retrieve a named property, that name is *guaranteed* to be valid, then it is justified to relax the exception class. If subsequently you still end up with an exception being thrown that percolates up the call chain because it was not explicitly trapped at the point of invocation, then this can only be because the precondition you had supposedly proven was not actually attained, at which point you don't have a "simple error", you have a major design flaw.

So I stand over my earlier response, and would add a caveat motivated by José, which advises anyone taking this route to be very careful about ensuring that the relaxation of the exception type is compensated by appropriate verifiable preconditions.

Similar concerns should be noted when dealing with implementations in other languages.

---Rotan

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of JOSE MANUEL CANTERA FONSECA
Sent: 26 November 2009 8:13
To: Jo Rabin; [hidden email]
Subject: RE: Unwanted (?) exceptions in DDR Simple API spec

Hi Jo,

although it can be possible I would not recommend it for the sake of robustness of the code, imagine for instance  a situation in which the names of the properties are obtained dynamically (for example from a file) and you end up having the name of a property which does not exist. If you don't capture exceptions explicitly your program will end unexpectedly and won't be able to recover from a simple error

So I would not take advantage of holes in the spec to satisfy certain use cases and leave the door open to break other situations Actually the majority of exceptions in Java APIs are regular exceptions that have to be captured explicitly

Best Regards


-----Mensaje original-----
De: [hidden email] [mailto:[hidden email]] En nombre de Jo Rabin
Enviado el: miércoles, 25 de noviembre de 2009 16:06
Para: [hidden email]
Asunto: 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