12 messages in org.apache.jackrabbit.oak-devRe: Exceptions used in oak-core| From | Sent On | Attachments |
|---|---|---|
| Angela Schreiber | Mar 22, 2012 2:48 am | |
| Michael Dürig | Mar 22, 2012 3:04 am | |
| Julian Reschke | Mar 22, 2012 3:53 am | |
| Michael Dürig | Mar 22, 2012 4:17 am | |
| Jukka Zitting | Mar 22, 2012 4:20 am | |
| Michael Dürig | Mar 22, 2012 4:35 am | |
| Thomas Mueller | Mar 22, 2012 5:49 am | |
| Thomas Mueller | Mar 22, 2012 5:56 am | |
| Thomas Mueller | Mar 22, 2012 6:03 am | |
| Julian Reschke | Mar 22, 2012 6:12 am | |
| Michael Dürig | Mar 22, 2012 6:25 am | |
| Angela Schreiber | Mar 27, 2012 6:07 am |
| Subject: | Re: Exceptions used in oak-core | |
|---|---|---|
| From: | Michael Dürig (mdue...@apache.org) | |
| Date: | Mar 22, 2012 4:35:52 am | |
| List: | org.apache.jackrabbit.oak-dev | |
On 22.3.12 11:20, Jukka Zitting wrote:
we decided that quite some core functionality of the JCR API will effectively be executed and validated on the oak-core-layer such as for example authentication, authorization or the complete versioning API. these validation needs to comply to the API contract defined by JSR 283/333, which define comprehensive lists of reasons for failure and the corresponding exceptions.
Here's the full list of RepositoryException subclasses defined in JSR 283:
AccessControlException AccessDeniedException ActivityViolationException ConstraintViolationException InvalidItemStateException InvalidLifecycleTransitionException InvalidNodeTypeDefinitionException InvalidQueryException InvalidSerializedDataException ItemExistsException ItemNotFoundException LabelExistsVersionException LockException LoginException MergeException NamespaceException NodeTypeExistsException NoSuchNodeTypeException NoSuchWorkspaceException PathNotFoundException ReferentialIntegrityException UnsupportedRepositoryOperationException ValueFormatException VersionException
Some of these can and should be handled entirely in oak-jcr (NamespaceException, UnsupportedRepositoryOperationException, ValueFormatException, etc.) and some I don't think we intend to support in any case (InvalidLifecycleTransitionException).
Ack.
The rest I think we need to go through case-by-case and figure out how those cases are best handled on the Oak API level. Whether to use return values (null, error codes, etc.) or exceptions depends on each particular case.
Ack.
what was your preference when it comes to those exceptions? should oak-core define it own set of exceptions that then would need to be converted to javax.jcr.*Exception in oak-jcr or should oak-core throw JCR exceptions?
As a general rule I'd rather avoid having a JCR dependency in oak-core, but obviously it doesn't make much sense to just duplicate all JCR exceptions in Oak. I'd say we should first look at the actual cases as outlined above to see how many of the exception types we really need, and decided on how to proceed once we have that information.
Generally I agree with Michael's view in that exceptions should be used only for truly exceptional cases. For example, if we expect that a save() call may fail because of validation errors, then it would IMHO be best for the return value of the related Oak commit() method to indicate whether the operation succeeded and contain relevant details in case of a failure. Oak-jcr can then turn that information to an appropriate exception to meet the JCR API contract. Only unexpected cases like a network failure should result in exceptions being thrown.
I think this issue also extends to the Microkernel. Currently the Microkernel throws a MicroKernel exception in various places where the caller is expected to handle that exception (i.e. item not found, revision not found...). IMO we should change this also and use exceptions only for unexpected conditions which the caller can't to anything about. Otherwise we need to include more information about the cause of the exception. Currently the only indication is the error message string which makes it hard to tell exception causes apart further up the call stack.
Michael