[jdom-interest] JDOM2 and Runtime Exceptions
mike at saxonica.com
Wed Jan 18 01:12:23 PST 2012
On 18/01/2012 03:31, Rolf Lear wrote:
> Hi all.
> Recent discussions have highlighted the area of how JDOM handles some
> exceptions. In particular the context was XPath expressions. JDOM
> specifies (and 'always' has specified) that XPath throws JDOMException
> in the event of a failure on XPath. This has been 'questioned' from
> the perspective that this would not be the fault of JDOM if the XPath
> expression failed to compile, or evaluate.
If A calls B, and B calls C, and C fails, I think it's very much an open
question whether B should attempt to translate/interpret any errors
coming from C before passing them back to A. To some extent it depends
on the level of transparency - if it's obvious to A that the request
will involve a call on C, then perhaps passing back C's exception
unchanged is reasonable. But if B wants to encapsulate C, and have
flexibility to choose different service suppliers (e.g. to call D
instead of calling C), then it's tough on A to pass back an exception
from a component it didn't know was involved. Might JDOM ever choose to
invoke a different XPath provider, or to include its own XPath engine?
For example, one that supports XPath 2.0? In that case, exposing
third-party exceptions would be an embarrassment.
> Exceptions that are outside the control of the programmer, like
> IOException, should be thrown and caught, but an illegal XPath is more
> of a bug/programming error than an Exception, and hence should be
> treated more like a NullPointerException, IllegalArgumentException,
> IndexOutOfBoundsException, etc.
Again this is an open question. URISyntaxException is very similar to a
compile-time XPath exception in this regard, and that is a checked
exception (and yes, it can be a pain). On the other hand
PatternSyntaxException is unchecked. There's no logical reason to make
I'm one of those who believes that the discipline and extra effort
caused by having to think about exceptions makes for better engineered
and more robust programs. I hate C# from this perspective; you never
know whether you have tested the exception handling code in your
application adequately. Similarly StAX is a mess from the exception
handling point of view - Sax, where every method can throw SAXException,
is much easier to work with.
> Would love some thoughts on this....
I don't think you'll please everyone here, but even without the
compatibility implications, I'm not convinced that moving to unchecked
exceptions would be an improvement.
More information about the jdom-interest