> Validating path syntax and the value of the "operand" parameter to
> the comparison(...) method are examples.
I agree, but the API should be clearer about that. In various locations
it declares an InvalidQueryException without saying under what
circumstances it will (or actually may) throw the exception.
In some places the API declares an InvalidQueryException for
situations that are impossible to detected. This should be fixed as
- Tests whether a node in the default selector is a child of a node
- reachable by a specified absolute path.
- @param path an absolute path; non-null
- @return the constraint; non-null
- @throws javax.jcr.query.InvalidQueryException
- if the query has no default
- selector or is otherwise invalid
- @throws javax.jcr.RepositoryException if the operation otherwise fails
public ChildNode childNode(String path) throws InvalidQueryException,
RepositoryException // CM
For an implementation it is impossible to find out if there is a default
selector, because that's a choice the caller will make independently of
this call, or he might not even create a Selector at all.
> Since we don't require validation to be performed until the
> query is execute()d, there's no implementor burden by allowing
> validation to be performed earlier.
Agreed. But for simplicity of the API and usability we should be careful
when declaring exceptions. If a client has to write code for an exception
that is never thrown, what good is it?
> From an API caller's standpoint, I think it's better to report problems
> sooner, because it's more clear where the problem lies.
Agreed. I'm OK with keeping the InvalidQueryExceptions. But let the API
be clear in what situations the InvalidQueryException may be thrown by
The only situation I can think of is a malformed path or name. But as
you mentioned an implementation is not required to perform that check
before the query is executed.