Hi, On Mon, Apr 22, 2013 at 1:00 PM, Angela Schreiber <[email protected]> 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. BR, Jukka Zitting
