> > Do you mean that the context info for a (hyptohetical) method like > doSomething(LinearOperator a, LinearOperator b) > would be like > offending operator: a > or > offending operator: b > ? > > If so, is it not enough to just throw the exception? Won't it be obvious > which operator is "offending" by looking at the line number in the stack > trace? > In your example, the answer is definitely yes. And from this point of view, using context is probably a very flexible solution, because we would provide some context only where it would really be needed : sometimes, a reference to the offending operator would certainly be useless. Thus, in your example, if the exception is some sort of DimensionMismatchException, I do not really need to know more than : a (or b) has wrong dimensions. Fix is easy.
But I can think of other cases where the answer is probably no. For example, let us consider the Unpreconditioned Conjugate Gradient method. In this case, if a NonPositiveDefiniteLinearOperator is thrown, there is no ambiguity as to which operator is the cause (there is only one operator). However, the context would also hold a reference to the offending vector x, which could be invaluable. Let's assume I have proved mathematically that a (huge) linear operator a is positive definite. I go on implementing it, and pass it to the CG method, which throws a NonPositiveDefiniteLinearOperator. This means that during the iterations, the solver has found this rare counter-example x which proves that my implementation is faulty (x is such that x'.a.x <= 0). Just knowing that my implementation has a bug is already quite good. But retrieving a *reference* to the offending vector x would allow me to reproduce the bug *outside* the iterations of the CG solver. In other words, having this kind of context with documented keys would help the end-user debug his own code. I hope I'm making my point clearly, there. Best regards, Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
