You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Thomas Müller <th...@day.com> on 2010/02/28 16:41:11 UTC
[jr3] Exception Handling
For Jackrabbit 3, I would like to improve exception handling. Some ideas:
== Use Error Codes ==
Currently exception message are hardcoded (in English). When using
error codes, exception messages could be translated. I'm not saying we
should translate them ourselves, but if somebody wants to, he could.
Disadvantage: it's more work to maintain, specially if Jackrabbit is
split into multiple projects. Every project could have it's own
message list, or the list could be centralized.
I'm not sure if it's worth it. What do you think?
== Include the Jackrabbit Version in Exceptions ==
This is mainly to simplify support: it's very easy to say what version
was used when somebody posts an exception message. Example:
"Repository is closed [1000-3.0.1003]" - this would mean error code
1000, Jackrabbit version 3.0, build 1003. The build number alone would
be enough, but for the user it may be better to also include the
version.
Also, it will allow looking at the source code without having to
download the source code of the correct version, even without having
to install an IDE. I wrote a simple JavaScript application:
http://www.h2database.com/html/sourceError.html - if you paste an
exception in the 'Input' text area, it will link to the source code
and display additional information. The source code is in a IFrame
that links to the right tag in the source repository. For example, if
you paste the following exception:
Syntax error in SQL statement "SELECT * FORM[*] TEST " [42000-130]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:317)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.get(DbException.java:145)
at org.h2.message.DbException.getSyntaxError(DbException.java:180)
at org.h2.command.Parser.getSyntaxError(Parser.java:475)
You will be able to browse the source code in the "Source Code" frame.
If Jackrabbit is split into multiple projects, there would be multiple
versions. There are solutions for this, but as a start, it's easier to
just use this mechanism in one project only (Jackrabbit Core).
Regards,
Thomas
Re: [jr3] Exception Handling
Posted by Guo Du <mr...@gmail.com>.
On Mon, Mar 1, 2010 at 9:32 AM, Michael Dürig <mi...@day.com> wrote:
> What about using something like a hash code (for example of the current
> stack trace) as error code? These would then automatically serve as hash
A good sample to deal with error messages:
http://publib.boulder.ibm.com/infocenter/ltscnnct/v2r0/topic/com.ibm.connections.25.help/r_error_codes_news.html
For a given error message:
CLFWX0019E: PUT HTTP method is not supported for this URL.
It contain a prefix "CLFWX" tell which component is coming from, and
it end with "E" means error. (W=Warn, I= Info)
The rest of the error message are supposed to be translated to other
languages. So even for none English users, we can still tell what's
going wrong from the error code.
-Guo
Re: [jr3] Exception Handling
Posted by Michael Dürig <mi...@day.com>.
Dominique Pfister wrote:
> I wouldn't call it error code, then: every time something changes
> either in the calling code or in the code throwing the exception,
> you'll get a different hash code.
Agreed, the stack trace might be too unstable. But I still like the idea
of using something cryptic for error codes. To see what I mean try
Googling for "error 1" and "error 0x800cccff". The second query gives
much more precise results.
OTOH it needn't be the error code. We could also include it just at what
it is, a hash tag.
Michael
>
> Dominique
>
> On Mon, Mar 1, 2010 at 10:32 AM, Michael Dürig <mi...@day.com> wrote:
>>> == Use Error Codes ==
>> What about using something like a hash code (for example of the current
>> stack trace) as error code? These would then automatically serve as hash
>> tags for Google searches. That is, errors pasted into a discussion forum
>> would be indexed by Google. Searching for 'Error
>> 6df8c9ef2aa1cf7b04b52939b7c1cd7e' would then practically unambiguously lead
>> to that post.
>>
>> Michael
>>
>>
>>
Re: [jr3] Exception Handling
Posted by Dominique Pfister <do...@day.com>.
I wouldn't call it error code, then: every time something changes
either in the calling code or in the code throwing the exception,
you'll get a different hash code.
Dominique
On Mon, Mar 1, 2010 at 10:32 AM, Michael Dürig <mi...@day.com> wrote:
>> == Use Error Codes ==
>
> What about using something like a hash code (for example of the current
> stack trace) as error code? These would then automatically serve as hash
> tags for Google searches. That is, errors pasted into a discussion forum
> would be indexed by Google. Searching for 'Error
> 6df8c9ef2aa1cf7b04b52939b7c1cd7e' would then practically unambiguously lead
> to that post.
>
> Michael
>
>
>
Re: [jr3] Exception Handling
Posted by Michael Dürig <mi...@day.com>.
> == Use Error Codes ==
What about using something like a hash code (for example of the current
stack trace) as error code? These would then automatically serve as hash
tags for Google searches. That is, errors pasted into a discussion forum
would be indexed by Google. Searching for 'Error
6df8c9ef2aa1cf7b04b52939b7c1cd7e' would then practically unambiguously
lead to that post.
Michael
Re: [jr3] Exception Handling
Posted by Alexander Klimetschek <ak...@day.com>.
On Sun, Feb 28, 2010 at 16:41, Thomas Müller <th...@day.com> wrote:
> == Use Error Codes ==
>
> Currently exception message are hardcoded (in English). When using
> error codes, exception messages could be translated. I'm not saying we
> should translate them ourselves, but if somebody wants to, he could.
>
> == Include the Jackrabbit Version in Exceptions ==
>
> This is mainly to simplify support: it's very easy to say what version
> was used when somebody posts an exception message. Example:
> "Repository is closed [1000-3.0.1003]" - this would mean error code
> 1000, Jackrabbit version 3.0, build 1003. The build number alone would
> be enough, but for the user it may be better to also include the
> version.
>
> Also, it will allow looking at the source code without having to
> download the source code of the correct version, even without having
> to install an IDE. I wrote a simple JavaScript application:
> http://www.h2database.com/html/sourceError.html - if you paste an
> exception in the 'Input' text area, it will link to the source code
> and display additional information.
+1
I like the result that error stack trace analysis can be automated
then. This makes it much faster for a dev knowing the internal code to
spot any error, w/o having to find the proper version of a source file
first (and w/o having to ask for the jackrabbit version on the list).
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com