jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Exceptions used in oak-core
Date Thu, 22 Mar 2012 11:20:32 GMT
Hi,

On Thu, Mar 22, 2012 at 10:48 AM, Angela Schreiber <anchela@adobe.com> wrote:
> i would like to discuss the nature of exceptions that will
> be thrown from the oak-api/spi module.

Good point.

> 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).

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.

> 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.

BR,

Jukka Zitting

Mime
View raw message