Hi,
On Thu, Mar 22, 2012 at 10:48 AM, Angela Schreiber <[email protected]> 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
