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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
