jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Exceptions used in oak-core
Date Tue, 27 Mar 2012 13:08:06 GMT
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

Mime
View raw message