Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F6B0EAF.9080600@apache.org>
Date: Thu, 22 Mar 2012 11:36:15 +0000
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Exceptions used in oak-core
References: <4F6AF574.3010503@adobe.com>
 <CAOFYJNZwJS2_BMEXS+HXLFapGH6pGnn48MqBDqHSZZfLgf+Bkg@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNZwJS2_BMEXS+HXLFapGH6pGnn48MqBDqHSZZfLgf+Bkg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


On 22.3.12 11:20, Jukka Zitting wrote:
>
>> 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).

Ack.

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

Ack.

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

I think this issue also extends to the Microkernel. Currently the 
Microkernel throws a MicroKernel exception in various places where the 
caller is expected to handle that exception (i.e. item not found, 
revision not found...). IMO we should change this also and use 
exceptions only for unexpected conditions which the caller can't to 
anything about. Otherwise we need to include more information about the 
cause of the exception. Currently the only indication is the error 
message string which makes it hard to tell exception causes apart 
further up the call stack.

Michael