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-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
