commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Implementation of Conjugate Gradient (MATH-581)
Date Thu, 04 Aug 2011 12:21:27 GMT

> I'm OK to define a new exception. From your PS, I understand that I should
> wait until what I've already submitted ( has been committed
> until I submit a patch containing the new exception. Is that right?

I would have thought the other way around: First commit the exception than
commit the code that use it (i.e. a new patch). That will avoid changing
that code afterwards just to use the new exception.

> I don't think it's necessary to open a new JIRA ticket for this, do you?


> Finally, a design issue. I would like the
> NonSquareLinearOperatorException to have an accessor to the actual
> LinearOperator which was the cause of this exception. It seems to me that
> NonSquareMatrixException does not offer this opportunity, so having the latter
> inherit from the former might be difficult. Should I give up this accessor,
> then? I think it would be a pity. As an example: the constructor of a
> preconditioned iterative solver requires TWO LinearOperators, both of which
> must be square. If an exception is raised, it would be nice (although not
> absolutely essential, since I can always test a posteriori the size of each
> operator) to know which operator was faulty.

I'm still wondering whether it is useful to provide access to a high-level
object (such as "RealLinearOperator" or "RealMatrix") from an exception.
What are you supposed to do with it?  Printing cannot be a default option
since, from what I understand, it could be huge.

Also, if keeping those data in the exception is useful in some circumtances,
we could use the "ExceptionContext" feature that was recently implemented.
Code would look like
 * [...]
 * @throws NonSquareLinearOperatorException when [...].
 * The offending operator can be accessed from the exception context (cf.
 * {@link org.apache.commons.math.exception.util.ExceptionContext}, using
 * the "operator" key name.
public void doSomething(RealLinearOperator op) {
   // ...

   if ( /* test */ ) {
     final NonSquareLinearOperatorException nslo = new NonSquareLinearOperatorException();
     nslo.getContext().setValue("operator", op);
     throw nslo;

   // ...

Yes, that's more code to write (but you only do it once), but it makes a
clear separation between not often used data, and default information that
will usually end up printed on the console.

I would thus also propose to remove the "getOffending..." from the existing
exceptions (and replace them likewise).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message