Hello Sébastien.
> >
> > One thing that I think we all agree on; however, is that we should not be
> > designing exceptions or APIs that throw exceptions with the intent that
> > applications catching exceptions should parse the messages or search
> > the message content for specific strings.
> >
> I do apologize, I am not sure I fully understand. Please let me try
> again. I agree, parsing e.getMessage() would be horrible, but that was
> not what I had in mind.
>
> Let's say that a NonPositiveDefiniteLinearOperatorException e is
> raised, and I want to retrieve the operator in question. One way to do
> it would be to have a getter
> e.getOffendingLinearOperator()
> In MATH-581, following the discussion entitled "Implementation of
> Conjugate Gradient (MATH-581)" (started aug, 4), we finally went for
> the more flexible
> e.getContext().getValue("offending operator")
I am assuming that the main difference between using the "ExceptionContext"
and passing information in the exception's constructor is that in the
latter, the information will unconditionally appear in the string returned
by "getMessage". The contents of the "ExceptionContext" must be retrieved
manually because, as is the case for iterative solvers, it could lead to a
huge message.
Thus, when debugging an application, one can catch the exception and loop
over the context keys using the "getKeys()" method, without needing to need
the key names in advance. [Thus I would keep the key names "private".]
> The issue then is a proper handling of the key names ("offending
> operator" in the present case). Should the key names be assigned
> arbitrarily by the method which throws the exception, or stored (as a
> constant String) in the exception itself. My point is that in some
> circumstances, it is possible to have the exception store "typical"
> keys, which can be consistently used by everyone throwing such an
> exception, with the further possibility to add supplementary context
> to this exception, with freely chosen key names.
It would be inconsistent to have two ways for accessing information stored
in an exception class (hard-coded strings vs accessors). The context was
primarily to be a "user" facility but I thought that it would come handy
if we want to avoid the risk of flooding the console.
One could view that that information stored in the exception context does
not strictly belong to the exception class; the exception is a "vehicle"
that allows more detailed (i.e. _too_ detailed in most cases) debugging
information to travel easily upwards.
Another point is that CM is not allowed to print non-localized messages.
I'd say that the exception context being printed on demand only, it could
stay away of the "LocalizedFormats" machinery without being a breach on the
requirement.
> [...]
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
