commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: svn commit: r1035003 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/exception/util/MessageFactory.java test/java/org/apache/commons/math/exception/util/MessageFactoryTest.java
Date Sun, 14 Nov 2010 21:38:32 GMT
Le 14/11/2010 22:19, Luc Maisonobe a écrit :
> 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: http://svn.apache.org/viewvc?rev=1035003&view=rev
>>> 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!
> 
> Yes.
> 
>>
>> 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.

It should be fixed now, in r1035072 and r1035073.

I left the other change (allowing either specific or general to be null)
as I still consider its worth providing both ways. So my question on
MATH-440 is still valid and I would like to remove the general stuff
from user message, to make sure we don't mess with what the user want.

Luc

> 
> Sorry for having followed the wrong track.
> 
> Luc
> 
>>
>> Best,
>> 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