commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Date Sun, 02 Oct 2011 14:38:13 GMT

> 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.

The first time I saw this quote, it also took me a lot of time to understand
what they were talking about. Indeed, the mere fact of having a hard time
understanding it indicates that the quote perfectly illustrates the point!

> >
> > +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

Conceptually, the exception are related; however, as we already discussed,
it is difficult to make them share an implementation.
It would have been possible by having (marker) interfaces, but that seems to
be overkill for something that most of the time ends up in aborting the

> 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
> SingularMatrixException).
> Do you think that the discussion is well summed up?

Almost (cf. below).

> 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?

I hadn't thought of it, but in the line of "leaner is better", I like
number 2. However, in some application contexts, people would probably
prefer to keep the "Matrix" part of the exception name, thus number 1.


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

View raw message