commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: svn commit: r1035003 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/exception/util/ test/java/org/apache/commons/math/exception/util/
Date Sun, 14 Nov 2010 21:19:13 GMT
Le 14/11/2010 21:57, Gilles Sadowski a écrit :
> Hi Luc.

Hi Gilles,

>> Author: luc
>> Date: Sun Nov 14 15:06:11 2010
>> New Revision: 1035003
>> URL:
>> Log:
>> fixed message building so the behavior matches the existing javadoc:
>> general arguments are the ones remaining after the specific ones have been handled
> I'm afraid that it was intended the other way around! A message log must
> come out as:
> <problem_general_description>: <specific_context_description>
> Although I did try doing something along your changes, I did not pursue it
> because it would mess the existing enums: it makes it impossible to use the
> same parameters for both the general description and the specific ones!

Then the javadoc was wrong. I tried to get the code consistent with it
by changing the code. We can get consistency by changing the javadoc ...

> For example a general problem is "DimensionMismatchException"; and it is
> clear how to format a "general" message that describes this problem and for
> this, you use up two parameters which are
>  1. the wrong dimension
>  2. the expected dimension
> If a more "specific" message is provided, it would still need these two
> parameters, but they are gone now!


> Doing it the other way around, as I think was the purpose of your change
> (and of your question about "MathUserException") still has the same
> shortcoming: "specific" uses up the parameters and they are not available
> anymore for "general".
> I think that a more flexible framework would be necessary to accomodate
> that functionality (which I didn't want to suggest since a large overhaul
> would again ensue).

The framework is already complex enough, I would not like to have it
more complex.

> The implementation in fact allowed redundant message, where "redundant"
> refers to having the parameters appearing more than once.
> With your change, the redundancy will appear at the point where the
> exception is instantiated. E.g. if SPECIFIC_PATTERN would use two
> parameters, one would need
>   new DimensionMismatchException(SPECIFIC_PATTERN, 1, 2, 1, 2);
> while with the other constructor, it must be:
>   new DimensionMismatchException(1, 2);
> I think that this is highly undesirable.
> Sorry for not having written a clearer class documentation that would have
> mentions this caveat.

I'll revert the change and make the javadoc match the earlier code.

Sorry for having followed the wrong track.


> Best,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message