Le 14/11/2010 23:22, Gilles Sadowski a écrit :
> Hi.
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.
You are right, but for a user exception, it's not commons-math that
knows the meaning, but the user. So the user should have access to the
general specifier. For now, we hide this access and provide him only the
specific part.
>
> 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.
We are in the very rare case where the type of the exception
(MathUserException) does *not* provide information. All information (and
it is very important for the user) is either in a wrapped exception
(IMHO it is the best use), or in the message. I just want to let the
user provide what he wants when he build his instance, not bothering at
commons-math level about it (i.e. not adding extra parts without his
consent) and letting him recover his instance untouched at top level.
>
>> 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".
Yes. My last comment in MATH-44 is wrong by the way, so I continue here
as the list is more suited for discussion. It IS possible to have a
non-ambiguous set of constructors despite the variable arguments. In
fact, it is already what we have in MessageFactory with the two static
methods buildMessage.
So what I propose the following set of constructors :
- no argument
-> this would lead to the default message USER_EXCEPTION
- a throwable
-> this would lead to the default message USER_EXCEPTION
- a throwable and one pattern
-> this would be used to specify the generic part
- a throwable and two patterns
-> this would be used to specify both the generic
and the specific part
In fact, all these constructors end up calling the last one, by adding
some null arguments. All arguments can be null.
> I think that the rest of the code should be left as it was.
Yes, I only add constructors to a class which provides some boilerplate
for users and which commons-math does not use by itself. So this affects
strictly nothing in commons-math, it only improves user control.
best regards,
Luc
>
>
> Regards,
> 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
