On Mon, 04 Nov 2013 09:47:32 -0800, Phil Steitz wrote:
On 11/4/13 2:08 AM, Luc Maisonobe wrote:
Le 04/11/2013 00:59, Gilles a écrit :
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.
Exceptioncontext has been add more than two years ago (revision
1099771,
2011-05-05). Since then its setValue method is called in only two
places
in regular code (not counting test code): in SymmLQ.java and in
ConjugateGradient, so this key/value features seems a failure to me.
Its
message part on the other hand is used everywhere, and I even use it
outside of Commons Math since I introduced the
ExceptionContextProvider
interface in September 2001 (we had a short discussion about it
there:
<http://markmail.org/message/q7gv5mqx62w735pc>).
So I agree ExceptionContext is a useful class, and perhaps it would
need
some changes. As per the comments above, I would suggest to further
improve the used part, typically allowing to retrieve the patterns
and
arguments which I really miss, as the patterns are already set
everywhere and can be used externally to also identify a particular
exception. I have no real idea about improving the currently almost
unused key/value feature, but fear it would imply a tremendous work.
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.
This may be true, but finding it is also a lot of work, with little
benefit. Feel free to do it if you want, though.
I have scanned for exact duplicates quite a few times and never
found any. There are quite a few that are similar, but differ in
material ways (strict versus non-strict inequalities, endpoints
included / not included, etc.). Please do not "collapse" messages
at the expense of loss of specificity or correctness.
FAILED_BRACKETING
UNABLE_TO_BRACKET_OPTIMUM_IN_LINE_SEARCH
INVALID_BRACKETING_PARAMETERS
My position: the error (failed bracketing) should have its own
exception
type. The varying contexts could (do not have to) be part of the
message
built at exception instantiation.
If we want to include an indication of location (despite it is already
part of the stack trace, so it is _redundant_), we could perhaps add
methods
to the "ExceptionContext", e.g. "where(LocalizeFormats pattern)" (?).
Then, we would have thos patterns in the list:
BRACKETING
LINE_SEARCH
Note: INVALID and FAILED are redundant since the pattern is intended to
be
included in an exception.
A second "interesting" case is
INVALID_ROUNDING_METHOD
which mixes documentation with error description. Does anyone really
thinks
that the enumeration of the rounding methods in the error message is
necessary
or even helpful?
Gilles
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
