- From: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
- Date: Thu, 26 Nov 2009 09:12:56 +0100
- To: Jo Rabin <jrabin@mtld.mobi>, "public-ddwg@w3.org" <public-ddwg@w3.org>
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: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] En nombre de Jo Rabin Enviado el: miƩrcoles, 25 de noviembre de 2009 16:06 Para: public-ddwg@w3.org 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
Received on Thursday, 26 November 2009 08:13:33 UTC