Hello everyone,
>
> 0) key/value pairs that are "consistently used by everyone throwing
> such an exception" should be named properties of the exception. So
> in your example of the offending linear operator in
> NonPositiveDefiniteLinearOperatorException, the exception should
> expose a getOffendingOperator method.
> 1) key/value pairs that represent optional or context-variable
> properties of an exception *may* have key names defined in the class
> that throws the exception.
> 2) Whenever keys are "named" and included in API specification, we
> should ask whether or not specialized exceptions or named properties
> of the exceptions being thrown should be defined (i.e. it is a
> warning sign when these names surface in API documentation).
>
this sounds OK to me (I shall keep item 2 in mind). As I tried to
express earlier (Gilles actually did a better job at that than I did),
we went from a specialized getters solution to a "context-only"
solution in MATH-581
> > 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".]
>
Phil's suggestion is a mixture of both, based on rule 2. I'm OK to go
(partly) back to the former solution (specialized getters), in fact
the former patch is still attached to the JIRA ticket, so it should
not be too much work...
I still have two questions
1. Gilles seems to be indicating that any object passed to the
exception's constructor should be printed in the exception's message,
which is absolutely unpractical in the present case (hence the choice
of context). My question is: is it a CM requirement that *all*
exception properties be printed by e.getMessage()? I looked for the
answer on the "CM Developers Guide", but did not find anything.
2. My second question refers to what Gilles said earlier
>
> 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".]
>
I am not sure about the meaning of "private" here. The way I see it:
the name of the key is attributed by the class which throws the
exception, not the exception itself (hence it is "private" from the
perspective of the exception itself). However, to the benefit of
end-users, I think the key name may be kept as a public final static
String within the class. Is that correct?
All the best for now,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
