commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [MATH] Interest in large patches for small cleanup / performance changes?
Date Mon, 04 Nov 2013 18:11:32 GMT
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
>>>>>>> <> wrote:
>>>>>>>>> I had proposed that error messages be incrementally built

>>>>>>>>> from
>>>>>>>>> simple
>>>>>>>>> "base" patterns, to be assembled either at the point
>>>>>>>>> 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
>>>>>>>> from
>>>>>>>> elementary components that are individually translated and
>>>>>>>> assembled
>>>>>>>> later. See all the documentation about the ancient gettext
>>>>>>>> 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.
> 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.


My position: the error (failed bracketing) should have its own 
type. The varying contexts could (do not have to) be part of the 
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 
to the "ExceptionContext", e.g. "where(LocalizeFormats pattern)" (?).
Then, we would have thos patterns in the list:


Note: INVALID and FAILED are redundant since the pattern is intended to 
included in an exception.

A second "interesting" case is


which mixes documentation with error description. Does anyone really 
that the enumeration of the rounding methods in the error message is 
or even helpful?


> [...]

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

View raw message