commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [MATH] Interest in large patches for small cleanup / performance changes?
Date Mon, 04 Nov 2013 17:47:32 GMT
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
>>>>>> <luc@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.

Phil
>
> best regards,
> Luc
>
>> 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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message