Oak error codes

[Jukka Zitting <ju...@gmail.com>]

Hi,

I'd like to introduce error codes for the CommitFailedExceptions
thrown by various commit hooks and other components.

Like the immediately recognizable (and nicely googleable) "ORA-NNNNN"
codes used by the Oracle database, each individual Oak error condition
should have it's own code in addition to a textual message that
describes the issue. Something like "OakTypeNNNN" where "Type"
indicates the error category (like "Constraint" for constraint and
"Access" for access violations) and "NNNN" is a numeric code for that
specific problem.

Such error coding should allow us to avoid the somewhat awkward
CommitFailedException.throwRepositoryException() mechanism. And
documentation about common error scenarios could easily evolve in the
wiki with such error codes as page names.

BR,

Jukka Zitting

Re: Oak error codes

[Julian Reschke <ju...@gmx.de>]

On 2013-04-09 08:16, Jukka Zitting wrote:
> Hi,
>
> On Mon, Apr 8, 2013 at 6:42 PM, Alexander Klimetschek
> <ak...@adobe.com> wrote:
>> For localization it's also useful if you could pass through those codes in programmatic fashion:
>>
>> int OakException#getErrorCode() // or even using enums - YMMV
>
> Yep. I'm thinking of using a string for the "Type" part and an integer
> code for the "NNNN" one, with the wiki used as an informal registry of
> types and codes. That should fit the pluggable nature of Oak better
> than a fixed set of Enum values.
>
>> PS: Note that I am not talking about Java's Throwable#getLocalizedMessage(), as that's
>> generally useless, because the backend such as Oak usually does not and should not
>> know about the current UI language.
>
> Agreed. A better approach is the one used for example in HTTP where a
> "404 Not found" response results in a localized error message based on
> the browser interpreting the "404" error code and ignoring the "Not
> found" part (and typically also the body of the response).
> ...

Um. That's a mis-feature of IE which overrides the response body when 
it's shorter than a certain trigger length.

Best regards, Julian

Re: Oak error codes

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Apr 8, 2013 at 6:42 PM, Alexander Klimetschek
<ak...@adobe.com> wrote:
> For localization it's also useful if you could pass through those codes in programmatic fashion:
>
> int OakException#getErrorCode() // or even using enums - YMMV

Yep. I'm thinking of using a string for the "Type" part and an integer
code for the "NNNN" one, with the wiki used as an informal registry of
types and codes. That should fit the pluggable nature of Oak better
than a fixed set of Enum values.

> PS: Note that I am not talking about Java's Throwable#getLocalizedMessage(), as that's
> generally useless, because the backend such as Oak usually does not and should not
> know about the current UI language.

Agreed. A better approach is the one used for example in HTTP where a
"404 Not found" response results in a localized error message based on
the browser interpreting the "404" error code and ignoring the "Not
found" part (and typically also the body of the response).

BR,

Jukka Zitting

Re: Oak error codes

[Alexander Klimetschek <ak...@adobe.com>]

Good idea.

For localization it's also useful if you could pass through those codes in programmatic fashion:

int OakException#getErrorCode() // or even using enums - YMMV

Then applications can build their own localization dictionaries based on the (documented) error codes, without having to fiddle with the english exception messages.

Cheers,
Alex

PS: Note that I am not talking about Java's Throwable#getLocalizedMessage(), as that's generally useless, because the backend such as Oak usually does not and should not know about the current UI language.


On 05.04.2013, at 13:27, Jukka Zitting <ju...@gmail.com> wrote:

> Hi,
> 
> I'd like to introduce error codes for the CommitFailedExceptions
> thrown by various commit hooks and other components.
> 
> Like the immediately recognizable (and nicely googleable) "ORA-NNNNN"
> codes used by the Oracle database, each individual Oak error condition
> should have it's own code in addition to a textual message that
> describes the issue. Something like "OakTypeNNNN" where "Type"
> indicates the error category (like "Constraint" for constraint and
> "Access" for access violations) and "NNNN" is a numeric code for that
> specific problem.
> 
> Such error coding should allow us to avoid the somewhat awkward
> CommitFailedException.throwRepositoryException() mechanism. And
> documentation about common error scenarios could easily evolve in the
> wiki with such error codes as page names.
> 
> BR,
> 
> Jukka Zitting

Re: Oak error codes

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Apr 5, 2013 at 5:30 PM, Pontus Amberg <po...@gmail.com> wrote:
> As long as the code only is used internally or _always_ is accompanied with
> a message it is ok. I work at some projects where we have no internet
> connection and to encounter just an error code with no message is really
> annoying!

Indeed.

What I had in mind is to turn our exception messages from just
"message" to "OakTypeNNNN: message" so that the plain-text message is
always included. The extra error code (also accessible through extra
methods in CommitFailedException) acts as a key for finding more
information (i.e. not just what the problem was but how to resolve or
debug it, etc.) or for dispatching custom error handling code.

BR,

Jukka Zitting

Re: Oak error codes

[Pontus Amberg <po...@gmail.com>]

As long as the code only is used internally or _always_ is accompanied with
a message it is ok. I work at some projects where we have no internet
connection and to encounter just an error code with no message is really
annoying! I know that working without internet access is pretty uncommon
these days but it does still occur.

/Pontus


On Fri, Apr 5, 2013 at 3:50 PM, Angela Schreiber <an...@adobe.com> wrote:

> looks reasonable to me... that would also allow to write better
> commit hook tests that don't mix up the different type of failures
> and just pass by coincidence.
>
> angela
>
>
> On 4/5/13 1:27 PM, Jukka Zitting wrote:
>
>> Hi,
>>
>> I'd like to introduce error codes for the CommitFailedExceptions
>> thrown by various commit hooks and other components.
>>
>> Like the immediately recognizable (and nicely googleable) "ORA-NNNNN"
>> codes used by the Oracle database, each individual Oak error condition
>> should have it's own code in addition to a textual message that
>> describes the issue. Something like "OakTypeNNNN" where "Type"
>> indicates the error category (like "Constraint" for constraint and
>> "Access" for access violations) and "NNNN" is a numeric code for that
>> specific problem.
>>
>> Such error coding should allow us to avoid the somewhat awkward
>> CommitFailedException.**throwRepositoryException() mechanism. And
>> documentation about common error scenarios could easily evolve in the
>> wiki with such error codes as page names.
>>
>> BR,
>>
>> Jukka Zitting
>>
>

Re: Oak error codes

[Angela Schreiber <an...@adobe.com>]

looks reasonable to me... that would also allow to write better
commit hook tests that don't mix up the different type of failures
and just pass by coincidence.

angela

On 4/5/13 1:27 PM, Jukka Zitting wrote:
> Hi,
>
> I'd like to introduce error codes for the CommitFailedExceptions
> thrown by various commit hooks and other components.
>
> Like the immediately recognizable (and nicely googleable) "ORA-NNNNN"
> codes used by the Oracle database, each individual Oak error condition
> should have it's own code in addition to a textual message that
> describes the issue. Something like "OakTypeNNNN" where "Type"
> indicates the error category (like "Constraint" for constraint and
> "Access" for access violations) and "NNNN" is a numeric code for that
> specific problem.
>
> Such error coding should allow us to avoid the somewhat awkward
> CommitFailedException.throwRepositoryException() mechanism. And
> documentation about common error scenarios could easily evolve in the
> wiki with such error codes as page names.
>
> BR,
>
> Jukka Zitting