[
https://issues.apache.org/jira/browse/JCR-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560701#action_12560701
]
Alexander Klimetschek commented on JCR-1328:
--------------------------------------------
+1 for a specific exception as well.
The JCR API was one of my drivers for writing a blog post about exceptions [1].
IMHO the JCR API often fails point 2) I mention there, ie. the base exception
class (RepositoryException) is thrown in both specific (contingency) and
general error cases (faults). See also [2] for a nice introduction to the
difference between faults and contingencies. In this case the malformed path is
a contingency, ie. the client could react on it in some way or the other. But
if it is a connection error, we have a fault. It's a bit like the HTTP status
codes: a fault is a 5XX (the server did something wrong and the client cannot
do anything about it), a contingency would be a 4XX, ie. the client made a bad
request and could improve it.
I had a chat with David Nuescheler, the JSR-283 spec lead, about this topic and
he said that these problems should be mostly resolved now - but as it looks,
this is not the case. Maybe one should check the 2.0 API for all those cases
again?
Just my 2 cents for making a coder's life better...
[1] http://weblogs.goshaky.com/weblogs/alexkli/entry/exception_best_practices
[2] http://dev2dev.bea.com/pub/a/2006/11/effective-exceptions.html
> Session.itemExists implementation wrong
> ---------------------------------------
>
> Key: JCR-1328
> URL: https://issues.apache.org/jira/browse/JCR-1328
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.4
> Reporter: Felix Meschberger
> Attachments: JCR-1328.patch
>
>
> IMHO the implementation of the Session.itemExists(String) method is wrong
> when called with a malformed path such as "/a/b/c/*" (note the trailing
> star). According to the spec, the method must return "false" for a malformed
> path like this.
> In reality, the method throws a RepositoryException which is allowed to be
> thrown by the spec "if an error occurrs" (whatever that means). But catching
> this exception means, we cannot handle it: Is it a connection issue or a
> general repository problem ? If so, I cannot do anything about it. It is
> really a path problem, I can do something about it. But how do I know
> (without rebuilding internals) ?
> See also SLING-152 for more info.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
