Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Sun, 2 Oct 2011 16:38:13 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] rename o.a.c.m.linear.SingularMatrixException to
 SingularLinearOperatorException
Message-ID: <20111002143813.GT17021@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: 
 <CAGRH7Hq7CF4uSUJ6JGvDXAYE063rZoKWQOnLegi74GPaCC66kA@mail.gmail.com>
 <4E877BB0.7020803@gmail.com>
 <CAGRH7Hqm5qd+B3gzU4zfhatmdkK0DmVzP4GcgKQ0tE9reK8Ofw@mail.gmail.com>
 <4E87FDA1.5000409@gmail.com>
 <CAJwFCa0BV4G48U1C9p06A8e-zkN5QyXGUzSLzrwmMZeZc17E4A@mail.gmail.com>
 <CAGRH7HqwA+ubpQu=9q7UXS1_tJ1y8q8QBo6qZWboj=Q7VoEa0Q@mail.gmail.com>
 <20111002124334.GS17021@dusk.harfang.homelinux.org>
 <CAGRH7Homsc4rwJv79zJZkzYQ6sRNKcVyzp-bWn5yNh1a5wuxgg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAGRH7Homsc4rwJv79zJZkzYQ6sRNKcVyzp-bWn5yNh1a5wuxgg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: hel 20002; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at hel
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

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