[jdom-interest] JDOM2 and Runtime Exceptions

[Michael Kay]

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 
them different.

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.