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
