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