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, 10 Nov 2013 00:07:47 GMT
On Sun, 10 Nov 2013 00:27:28 +0100, Thomas Neidhart wrote:
> On 11/09/2013 11:21 PM, Gilles wrote:
>> 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.
>
> Which is also a pragmatic and valid approach here imho.

My point was that something can be worth, even if the user does not
see the difference. Sometimes the value appears later, if only in the
form of simplified code.

Some things are touched even if it really does not make a difference
to the user, e.g. blank spaces, indentation, etc.
This is for the _developer_.

>
> If there are no real user complaints about this topic (and I am not
> aware of any) and no other solution will greatly enhance the current
> state, it is really not worth doing it.

This thread was about "small cleanup"...

>
> Part of my day job is to debug very complex systems and the most
> important thing is that you get what you expect, i.e. according to 
> the
> contract of a method, which btw also includes the method name. 
> Detailed
> error messages are nice to have but not really required (as long as 
> you
> understand the purpose of the code which any user/developer of CM 
> should
> do).
>
> More meaningful error messages would make sense if our targeted 
> audience
> are really end-users but I think this is a bit far-fetched.
>
> My conclusion: the way we handle exceptions is not perfect but 
> totally
> sufficient imho.

Which way?
I recall that we discussed the inclusion of an ExceptionContext class,
which I implemented following a supposed "consensus". After not really
upgrading the code to take advantage of it, it is deemed not necessary
(because all was well and "sufficient" before it existed, I guess).



Gilles


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


Mime
View raw message