commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Date Sun, 02 Oct 2011 13:22:23 GMT
2011/10/2 Gilles Sadowski <>:
> Hi Sébastien.[1]
Hi Gilles,
took me some time to figure out what your [1] meant, but I think I got
it (or did I?)... I'm a bit on the slow side.
> +1 also because it is the standard style in Java (for better or worse).
> As I've pointed out somewhere else[2], to avoid an avalanche of exception
> classes[3], the default assumption should probably not be that every concept
> embodied in a Java class must have its own set of subsumed exceptions.
> Rather, failures are more of a concern that is cross-cutting along possibly
> unrelated (algorithm) classes. E.g. even if an operator is not always a
> linear operator, couldn't it be that using one or the other could trigger a
> "SingularOperatorException" (where the "ExceptionContext" would be used to
> more fully describe the specifics of each case)?
I understand that appropriate use of exceptions is in fact a quite
delicate design issue, which is far beyond my designing skills, so I'm
ready to take anything which sounds good to more experienced people.
Only, in the present case, I have a hard time figuring out from the
above discussion what *is* the best solution.

If I understood correctly, Phil would like to have two separate
exceptions, SingularOperatorException and SingularMatrixException,
with no inheritance link

Gilles leans on the one exception+context side (since a Matrix is a
linear operator therefore an operator). So if I understand Gilles
correctly, we would rename SingularMatrixException to
SingularOperatorException, and throw this exception each time we try
to invert an operator in the widest sense (linear or not, matrix or
not). I actually like that simple option. Also, I would like to remind
you that the present exception does *nothing* but display a standard
message (there is no state variable in the present

Do you think that the discussion is well summed up? Or can you think
of a better way to implement things? For the time, I see two options
1. Keep SingularMatrixException, add SingularOperatorException
2. Rename SingularMatrixException to SingularOperatorException and use
it more widely (and possibly move it to a more general package). Use
context if needed.
3. any other idea?

Looking forward to hearing your favored choice,

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

View raw message