commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [MATH] Interest in large patches for small cleanup / performance changes?
Date Mon, 04 Nov 2013 10:08:24 GMT
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
>>>>> <> 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 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:

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.

best regards,

> 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
>>>> 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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message