On Sun, 03 Nov 2013 15:33:12 -0800, Phil Steitz wrote:
On 11/3/13 2:57 PM, Gilles wrote:
On Sun, 03 Nov 2013 21:03:02 +0100, Luc Maisonobe wrote:
Le 03/11/2013 20:17, Ted Dunning a écrit :
On Sun, Nov 3, 2013 at 10:56 AM, Luc Maisonobe
<l...@spaceroots.org> wrote:
I had proposed that error messages be incrementally built from
simple
"base" patterns, to be assembled either at the point where the
exception
is going to be thrown or inside specific exceptions[2] (or a
combination
of both).
It often doesn't work. Sentences constructions are completely
different
in different languages, and it is impossible to simply buid up
from
elementary components that are individually translated and
assembled
later. See all the documentation about the ancient gettext for
example.
I think that a message good enough to convey the cause of the
failure can
in many cases be built from such blocks. I concede that it may not
be
perfectly formulated in a natural language, but even if it where,
the error
message are _rarely_ if ever clear,
I disagree with that statement. I think we have in general done a
pretty good job producing clear, understandable exception error
messages, which are very useful to users of a library.
My statement is not that the error message is not a well written
English (or French) sentence. It is that being in a correct natural
language does not help in figuring out what the caller code did to
trigger the error.
The low level cause can be conveyed with the "little blocks" too.
It seems we go in circles; every time I have to assure that I do
not, and never did, propose to suppress error messages!
What I suggested is to try and see whether the "ExceptionContext"
can be used more.
For the code
I work on, I will continue to do that, whatever contortions are
required to create them. I personally don't mind working with the
message pattern setup we have. The one improvement I would
appreciate / incrementally help with is an attempt at organizing
them a little better.
That was the purpose of my suggestions, which came up to implementing
the "ExceptionContext".
Again, this may not be the answer to all wishes in matter of conveying
error information, but how will we know if we don't even try?
It is quite possible that many duplicates ended up in the error
message list just because it was easy to miss the one that should have
been reused or that the existing ones where not quite appropriate to
the exception being thrown.
Gilles
Phil
an one needs to refer to the apidocs
in order to understand what caused the exception. There the error
condition
is hopefully (as it should) explained in a nice and clear sentences.
There are drawbacks in having these hundreds of messages patterns.
Modern printf implementations deal with this by numbered
arguments. This
is not a problem any more.
Which means you have a complete message with a sentence that
simply has
placeholders for variables parts. What I understand about Gilles
proposal is to go further in the way of small blocks like
COLUMN_INDEX,
CONSTRAINT, EVALUATION, INDEX, NORM, and build up from there. Is
it what
was initially meant?
Not sure I understand what you wrote. But, yes; where a
juxtaposition of
the blocks is good enough, we could readily use it. That will
reduce the list
quite substantially. When we get rid of all the similar patterns,
it will be
more acceptable to keep a few longer patters where really necessary.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
