On 2012-04-27 12:29, Thomas Mueller wrote:
Hi,
my preference was to just throw the jcr-exceptions where
ever this was appropriate and unambiguous. for example
namespaceexception, versionexception, constraintviolation...
I can't comment on NamespaceException, VersionException, and so on.
What I find problematic is, if almost all methods can throw a checked
exception. As an example, let's assume CoreValue.getString() could throw a
RepositoryException (when there is an error converting the value to a
string). If we do that, then we would have to add exception handling to a
That examples seems a bit academic right now, as CoreValue.getString()
indeed never throws (it delegates to toString()). The interesting case
are of course binary properties, and we'll have to think about what
needs to be done here.
*lot* of places. Within iterator implementations, within compareTo
methods, within toString methods,... It would make the code hard to read
and maintain. I find runtime exceptions are the better solution in many
cases. But yes, we should avoid using RuntimeException itself. I used it
quite a lot in the query engine actually, I will find a better way.
Best regards, Julian
