Hi. > > [...] > > > > I'll revert the change and make the javadoc match the earlier code. > > It should be fixed now, in r1035072 and r1035073.
Thank you. > I left the other change (allowing either specific or general to be null) > as I still consider its worth providing both ways. I don't understand. IMHO, it doesn't make sense to have no general description: if an exception exists, it has a meaning; it is that meaning that must be conveyed in the "general" description (in effect it is redundant with the exception's type; but that was your requirement: a localized message that some applications could print without referring to the stack trace. Moreover, by default the error message will be as follows: <exception type>: <problem_general_description>[: <specific_context_description>] where only the last part is optional (it will not be there if there is no "specific" pattern. In the case of "MathUserException" (as in most other cases), the "specific" part is provided at the instantiation of the exception object, while the "general" part is tied to the class definition (cf. above). Only the base classes of the exception provide constructors with 2 Localizable arguments, and they should rarely, if ever, be instantiated directly. > 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. I answered there, but obviously I'm still missing something (either what the problem is, or how to explain to you that there is no problem). So, to summarize, I think that the "general" pattern certainly cannot be null. However, if there is a case that users would want to base a hierarchy of exceptions on "MathUserException", then it should provide an additional constructor with 2 "Localizable". I think that the rest of the code should be left as it was. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
