commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
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 20:57:34 GMT
Hi Luc.

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

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


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

View raw message