On 10/1/11 1:21 AM, Sébastien Brisard wrote: > Hello, > I need to be able to throw an exception when an iterative linear > solver detects that a RealLinearOperator is singular. I would propose > to implement a SingularLinearOperatorException. Then, since RealMatrix > is derived from RealLinearOperator, it would be logical to have > SingularMatrixException inherit from SingularLinearOperatorException. > However, looking at the present impl of SingularMatrixException, this > exception does nothing fancy. So having two different exceptions might > be too much, I don't know. > So here are two proposals > 1. Rename SingularMatrixException to SingularLinearOperatorException > 2. Create SingularLinearOperatorException, and have > SingularMatrixException extend SingularLinearOperatorException. > > Which option (or any other) do you favor?
I would keep it simple and just have the two exceptions independent. The reason for this is that the activation contexts are likely to not often have much in common - i.e., as we have discussed before, a singular matrix exception will be triggered when a matrix that is not supposed to be singular is numerically singular (usually with some kind of threshold) while a singular operator exception is going to be triggered when an operator acts singularly. Of course, if the operator is represented by a matrix, then the specialization makes sense; but this will not always be the case, so there is not going to be meaningful state or implementation inheritance. Therefore I don't see much value in the inheritance (think about the value of catching the superclass or inheritance of state or implementation in the exceptions themselves). I would also shorten the name to SingularOperatorException. Phil > 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
