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: Clarification regarding Error Codes
Date Mon, 22 Apr 2013 10:58:32 GMT

On Mon, Apr 22, 2013 at 1:00 PM, Angela Schreiber <anchela@adobe.com> wrote:
> while i like the concept of the error codes in general, i am not
> fully happy with the current state of the implementation.

Yep, the implementation is still incomplete.

> for example in PrivilegeValidator i can now find the following
> error codes without having the slightest idea what was the meaning
> of the different codes:

There's no inherent meaning in the numbers, I just assigned them in a
rough sequence (jumping ahead when moving to a new class) to give most
exception causes a separate, unique code. In any case the exception
message should indicate the reason for the error, and the error number
helps to identify additional, external information about that issue.

> some are used multiple times... others not... what's the logic
> behind?

Ideally all distinct error conditions would have separate error codes.
I tried doing that in my initial pass but didn't keep too close a
track yet.

> how am i expected to deal with those codes if i add
> new validations?

The easiest approach is to just come up with new numbers for each new
exception. A better solution might be for each validator or component
to keep it's own list of constants for the distinct error codes. Or
some other approach could be used, depending on the preferences of
whoever implements a particular component.

> is there a list somewhere explaining the meaning
> of the various codes?

Not yet. My plan is to start collecting codes in
http://wiki.apache.org/jackrabbit/OakErrorCodes once the relevant bits
of code stabilize.

> in addition there are plenty of "conflict" string is hardcoded
> all over the place.

I started consolidating some of the type strings as constants in
CommitFailedException, but that's still incomplete.

To summarize, the implementation of OAK-764 is still incomplete. I'll
try to finish it up within the next week or so; meanwhile feel free to
jump in with questions, suggestions or changes.


Jukka Zitting

View raw message