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: | Angela Schreiber (anch...@adobe.com) | |
| Date: | Mar 27, 2012 6:07:43 am | |
| List: | org.apache.jackrabbit.oak-dev | |
hi jukka
thanks for the compilation.
i would like to discuss the nature of exceptions that will be thrown from the oak-api/spi module.
Good point.
Here's the full list of RepositoryException subclasses defined in JSR 283:
IMO the following exceptions of the the previously complete list have to some extend or the other a relation to oak-core and would IMO be raised there as the oak-jcr level wouldn't have the ability to perform the validation:
AccessControlException AccessDeniedException ActivityViolationException ConstraintViolationException InvalidNodeTypeDefinitionException InvalidQueryException LabelExistsVersionException LockException LoginException MergeException NodeTypeExistsException NoSuchWorkspaceException ReferentialIntegrityException VersionException
some sort of uncertainty regarding the following (because of Workspace#importXml):
InvalidSerializedDataException
imo only oak-jcr level:
InvalidItemStateException InvalidLifecycleTransitionException ItemExistsException ItemNotFoundException NamespaceException NoSuchNodeTypeException PathNotFoundException UnsupportedRepositoryOperationException ValueFormatException
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.
see above... one other area except from exception handling is for example the Credentials used to login.
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.
well, i am not convinced that this will work. there will be multiple different reasons for an operation on the oak-core level to fail. at the end you will end up having ambiguous status codes and a table that somehow tries to map them to jcr-exceptions. in this situation i would definitely prefer to have an exception being thrown on the oak-core level.
regards angela