There is another similarity with java.sql but I'm not familiar enough with that to know whether it serves as a good model.<div><br></div><div>I agree that the right thing to do with exceptions is hard to define and that Effective Java, for which I was a tech. reviewer, does not provide a template that is easy to apply.<br>
<br>As long as you're operating with a respect for checked exceptions, and are not on some mission to eradicate them, I expect that I'll like what you end up with.  Though deprecating the XPath support in JDOM1.0 is a big move...<br>
<br><div class="gmail_quote">On Thu, Jan 19, 2012 at 12:41 PM, Rolf Lear wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Leigh, all<br>
<br>
Despite my earlier mail referencing 'Effective Java', I went further in to<br>
the book, and it then contradicts itself in "item 59" which claims "Avoid<br>
unnecessary use of checked exceptions". It quite clearly contradicts the<br>
"item 58".... so even Bloch is not able to clearly define a 'rule' for<br>
checked exceptions.<br>
<br>
This process has been an exercise of frustration. It is quite clear that<br>
there is no clear 'right' way of doing things. There is no clear<br>
'precedent' on how it should be done either.<br>
<br>
Should XPath be like regex with a compile() and match() process, neither<br>
of which throw checked exceptions? The 'similarity' between XPath and Regex<br>
is quite convincing...<br>
<br>
Despite my earlier claim that xpath exceptions can be 'recovered from<br>
easily by the caller', I am not actually convinced. How do you 'recover'<br>
from a bad expression? How do you recover from an expression that does<br>
arithmatic with a value that is non-numeric? The argument for having<br>
checked exceptions is very unclear, and the convenience of unchecked<br>
exceptions is substantial.<br>
<br>
In a 'fresh' world, if I were writing the JDOM/XPath API from scratch, I<br>
think it would be very reasonable to throw an XPathSyntaxException for bad<br>
XPaths just like java.util.regex.Pattern throws PatternSyntaxException.<br>
Similarly XPathEvaluationException for issues encountered in the document.<br>
<br>
But backward compatibility is a big issue too.<br>
<br>
I think a big part of the API problem is because it is so closely tied to<br>
Jaxen. Jaxen throws checked exceptions too. I am not saying that checked<br>
exceptions are wring, but nor are they right.<br>
<br>
On the train this morning I played again with the JDOM/XPath API. I think<br>
I have a working solution, and I think I am more comfortable with it. It<br>
took a while to come to, but Java already has a well defined process for<br>
it... ;-) Deprecation.<br>
<br>
The thrown exceptions of a method are part of it's public API. I don't<br>
like the JDOMException thrown from XPath methods, so I am going to<br>
deprecate them.... JDOM 1.x users will get compile warnings, not errors.<br>
That's the compatibility problem solved.<br>
<br>
Then, I break down the XPath in to a 'compile' and 'evaluate' step, and<br>
make them throw unchecked exceptions that make sense for the particular<br>
issue.<br>
<br>
The new methods will be called 'XPath<T> compile(...)' instead of<br>
newInstance(...), and I think I will call the new execution methods<br>
List<T> matchAll(context)   and   T matchFirst(context)  .<br>
<br>
I have looked in to XPath 2.0, and by being smart with the API, and 'nice'<br>
with the option of applying a Filter directly to the XPath, I think it is<br>
reasonable to have the best of both worlds. With the changes as I have them<br>
now I think plugging in a different XPath2.0 back-end should be easy when<br>
one is available, and it will 'just work'. XPath 2.0 clearly differentiates<br>
between 'static analysis' portion of the XPath, and the 'dynamic<br>
evaluation' stage.<br>
<br>
Since this is such a grey area I think someone needs to just 'decide', and<br>
I think I will do just that.... Deprecate the old methods, keep their<br>
signatures unchanged (including exceptions), and implement a new, clean,<br>
unchecked, and generified set of methods.<br>
<br>
I like the idea of XPath being similar in 'feel' to RegEx.<br>
<br>
Time for me to get on the train again, and spend an hour playing with what<br>
feels right.<br>
<span class="HOEnZb"><font color="#888888"><br>
Rolf<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, 19 Jan 2012 11:35:58 -0800, Leigh L Klotz Jr wrote:<br>
> On 01/18/2012 01:12 AM, Michael Kay wrote:<br>
>> I don't think you'll please everyone here, but even without the<br>
>> compatibility implications, I'm not convinced that moving to unchecked<br>
>> exceptions would be an improvement.<br>
>><br>
><br>
> We use JDOM in our hand-written because it is a convenient, expressive<br>
> API, giving much of the compactness and other benefits we see from XPath<br>
<br>
> itself and other higher-level XML interfaces such as XQuery.<br>
><br>
> However, we haven't found the JDOM1 XPath Java interface to be<br>
> convenient or expressive, because of the verbosity and the checked<br>
> exceptions, which in our case are all programming errors of one sort or<br>
> another.  (We don't let end users type in XPath expressions.)  Instead,<br>
> we use a static JDOMUtil wrapper class with methods such as<br>
> selectElement, selectElements, selectAttributes, selectContent, and ref<br>
> (leaf-node value).<br>
><br>
> So for us, the JDOM XPath API is a implementation of a way to run XPath<br>
> expressions over JDOM objects, and not a convenient, expressive API that<br>
<br>
> we use to hand write Java code.<br>
><br>
> JDOM2 with the filters may offer an expressive API that would let us do<br>
> away with the profusion of select* utility methods, but with checked<br>
> exceptions it still won't be convenient, and we still won't use it<br>
> directly.<br>
><br>
> Leaving in the checked exceptions means less migration headache for<br>
> other users, and since we're not going to use it directly, it doesn't<br>
> matter much.  Another reason we may shift away from JDOM XPath API is<br>
> that we're disenchanted with Jaxen as well and are hoping to find a fast<br>
<br>
> (at runtime) way to use Saxon on JDOM from hand-written Java code.  That<br>
<br>
> probably won't use the JDOM XPath API at all.<br>
><br>
> Leigh.<br>
</div></div><div class="HOEnZb"><div class="h5"><br></div></div></blockquote></div></div>