On Sat, 09 Nov 2013 13:13:05 -0800, Phil Steitz wrote:
On 11/5/13 5:21 AM, Gilles wrote:
[...]
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
Look at the messages. These are different. They convey different
information and are appropriate in different contexts. See below.
I've argued that context information should be constructed at the
point where the exception is thrown (where the context is known).
Not all combinations of exceptions and context need be present in
the pattern list.
This is the essence of my proposal below.
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?
When I throw an exception, I want to provide an error message that
is meaningful in the context of the caller, i.e., that someone
looking at a log or stack trace can make sense of. That sometimes
means restating preconditions, sometimes pointing to boundary
conditions, sometimes giving hints describing common causes of the
exception - lots of different things that depend on the API, the
activation context and the nature of the exception. The natural
way
to do this is to use natural language sentences. Please allow me
to
retain a straightforward way to construct these messages and to
maintain the specificity and meaning of the messages.
IMHO, the level of details in the message is not needed: if the
exception
was thrown, the user should probably look at the documentation,
rather
than try another value at random; I'd say that it is harmful to
tempt the
users with something like "Pick another number". ;-)
[Shouldn't we rather provide function where the rounding type is
an enum?]
The main problem in those discussions is that you consider only
"toy"
situations, where the message generated by Commons Math should
make sense
wherever the exception is caught, and even if it is not caught.
What you keep failing to acknowledge is that in many real world
applications, reading exception stack traces and application logs
that contain error messages is an important operational activity.
Having clear error messages that make sense in the context of the
stack trace or application activation context makes the job of those
maintaining and debugging those applications easier. However hard
we decide to make it, I will continue to provide these.
IMO, the real problem is old habits, period. Despite your repeating it
over and over, I never expressed anything in the sense of having less
information in the error messages. [I don't get what the stack trace
has
to do here. And I just gave you a real example where whatever details
CM tries to provide, it will _never_ be sufficient because it cannot
know why the call failed; I suggested that the _same_ amount of
(necessary but not sufficient) information could perhaps be provided
with "little block" patterns glued with "addMessage" (or an improvement
thereof).]
Specific exceptions always provide more information than less specific
ones. Keeping low-level message (e.g. precondition failure) does not
preclude adding more specific messages when the context is known (that
happens in the code, and every little variant does not need to be
hard-coded in the currently overly long list of patterns).
My proposals were solely aimed at making the "preparation" of the
messages more efficient from a developer's perspective (e.g. no
scanning
of 300+ patterns).
Stalling the experiment in endless arguments makes it less and less
worth trying.
All in all, the main argument seems to always be that if the user
cannot see the difference, it is not worth changing the design.
Gilles
Phil
[I sometimes get a "failed bracketing" but knowing the values of
"the
endpoints [that] have the same sign" does not really help. I'd
rather need
to catch the exception, add more context info, rethrow, recatch,
etc.
And all this is quite more expensive than activating logging for
those
rare cases where numerical problems in the simulation trigger the
exception.]
Again and again, I do not mean that CM should not generate error
messages,
only that context info beyond a plain description of what happened
is
rarely usable a few layers above the failed call. And that context
info
could be provided with much less than 300+ different messages.
Having little "building blocks" would also make it easier to
retrieve
pattern/value pairs, as Luc seems willing to do, and more stable,
since
a single placeholder is unlikely to change meaning, while a
sentence that
contains many, could be turned differently so that the previous
placeholder
index could now refer to a different value.
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
