Hello.
> I'm OK to define a new exception. From your PS, I understand that I should
> wait until what I've already submitted (MATH-581-06.zip) 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?
No.
> 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
---CUT---
/**
* [...]
*
* @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;
}
// ...
}
---CUT---
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).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
