commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] Consistent use of ExceptionContext [was "using the ExceptionContext facility"]
Date Mon, 29 Aug 2011 18:54:12 GMT
Yes. Multiple scenarios can lead to the same exception, and context
seems to be a very flexible feature for this kind of situations.
However, as you said, this should be invoked as last resort. Context
elements we are dead sure will always be passed to the exception
should be implemented as attributes. Others should be (well
documented) context keys.
I like your extreme example, by the way. I kind of remember that
Imageio has the same kind of features: filters are invoked by a
string. With the added difficulty that documentation was very
difficult to find.
Anyway, I'll post a proposal as soon as I have the rights.
Sébastien

2011/8/29 Phil Steitz <phil.steitz@gmail.com>:
> On 8/28/11 11:56 PM, Sébastien Brisard wrote:
>> Hello everyone,
>> Looking at the present hierarchy of exceptions, I've had some further
>> thoughts, actually supporting the use of context rather than property
>> getters. Sticking with the same example, we have two exceptions
>> - NonPositiveDefiniteMatrixException: already implemented
>> - NonPositiveDefiniteLinearOperatorException: work in progress.
>> These two exceptions refer to the same mathematical concept, and the
>> former should probably extend the latter (just like AbstractRealMatrix
>> extends RealLinearOperator). However, these two exceptions are thrown
>> under quite different circumstances, with widely different parameters:
>> - If I understood correctly, NonPositiveDefiniteMatrixException is
>> thrown for example when a non-positive diagonal element is met,
>> - NonPositiveDefiniteLinearOperator is to be thrown when a *vector* x
>> is met, such as x'.a.x <= 0 (the entries of the operator as a matrix
>> are not accessible).
>> As you can see, the parameters of these exceptions will be different.
>> We could have a getOffendingOperator() method, but probably not a
>> getOffendingVector() method (since NonPositiveDefiniteMatrixException
>> has no offending vector in its state).
>>
>> Does that make sense?
>
> I see your point.  Despite my conservative instincts [1], I think it
> may actually be best to make both the current properties of the
> matrix version and the new properties of operator version optional
> members of the exception context.  There is nothing guaranteeing
> that the matrix version will always have a single diagonal element
> "witness."  Current activations (which use this for strict, semi and
> normal positive-definiteness) always have a diagonal element and
> threshold defined, but there may be other activations where a norm
> or other test may be used to signal positive definiteness failure.
> I now think that the row, column and threshold property of
> NonPositiveDefiniteException should be moved to the exception
> context and the row and col should be collapsed into one (since it
> is always a diagonal element that witnesses the failure and what is
> reported is always the same).  Regarding the operator version, we
> have two choices: keep the hierarchy corresponding to the math
> concept, or put the witness in the exception context.  My first
> reaction was to drop the hierarchy (with justification that the
> numerical failures were different), but that only makes sense if
> there will *always* be a witness in the operator case.  I am not
> sure about that, so I would say err on the side of flexibility and
> move the witness to the context.
>
> [1] I am probably too conservative on this because of bad
> experiences that I have had in the past with "data bags" of object
> properties used to avoid having to actually design things.  While we
> are in no danger of doing this, imagine the wonderful idea that we
> stop talking about exceptions altogether and via the miracle of the
> exception context, we just have one exception.  We define a NAME key
> and shove everything else into key/value pairs.  That is a
> caricature and I don't really mean it seriously, but you get the
> point.
>
> Phil
>
>
>>
>> Best regards,
>> Sébastien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message