commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Date Sun, 02 Oct 2011 15:24:41 GMT
On 10/2/11 7:38 AM, Gilles Sadowski wrote:
> Hello.
>> 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
> program...
>> 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

+1 for the reasons I gave above.
+1 for leaving the "linear" in the other names.

>> 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.
> Best,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message