commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [MATH] Interest in large patches for small cleanup / performance changes?
Date Sun, 03 Nov 2013 23:59:17 GMT
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.

> 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.

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


Mime
View raw message