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 Sun, 03 Nov 2013 13:33:31 GMT
On Sat, 2 Nov 2013 17:35:17 +0000, Sean Owen wrote:
> On Sat, Nov 2, 2013 at 4:49 PM, Phil Steitz <> 
> wrote:
>> If the improvements make a material difference [1], by all means
>> open tickets and submit patches.  If they are just cosmetic, my
>> personal opinion is this should be done in small commits
>> incrementally if at all [2].  It is OK to open master tickets to
>> track style / optimization changes and do the work to review and
>> commit them incrementally.  The master ticket should be preceded by
>> discussion here to make sure we are all in agreement that the
>> changes are appropriate.
>> You mention quite a few different kinds of thing above.  It is
>> probably best to break up into different discussion threads by
>> topical area and then open master tickets for the ones we agree to
>> fix / standardize.  Regarding the javadoc errors (broken javadoc
>> references, missing / incorrect @deprecates), there is no need for
>> discussion - just open tickets and we can commit the fixes.
> I agree with that. I'm going to file two JIRAs and probably leave it
> for now. No point in getting into minutiae.
> Let me turn it around: are there general clean-up tasks that people
> have wanted to do for a while but not gotten to? Maybe I could take a
> request or two and run with them.

One issue[1] is the unnecessarily high number of error patterns 
the "org.apache.commons.math3.exception.util.LocalizedFormats" class).
If one agrees that is is not necessary that every "throw" statement
must have its own pattern, it is possible to reduce the enormous
redundancy that exists in that list of patterns.

I had proposed that error messages be incrementally built from simple
"base" patterns, to be assembled either at the point where the 
is going to be thrown or inside specific exceptions[2] (or a 
of both).
Thus, the error message will be explicitly tied to a specific code
context, where we know all the information about the error and can add
it to the message that will be carried up the calling stack.

Best regards,

[1] Whether it is trivial or minutiae or a possible improvement, is 
     a matter of taste.
[2] If a similar error condition occurs at different places in the 

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

View raw message