commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] rename o.a.c.m.linear.SingularMatrixException to SingularLinearOperatorException
Date Sun, 02 Oct 2011 18:35:07 GMT
2011/10/2 Phil Steitz <phil.steitz@gmail.com>:
> 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.
>
> Phil
>>> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
OK, I'll commit something along these lines. Thank you everyone for your advice!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message