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: domain of sebastien.brisard@gmail.com
 designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
Sender: sebastien.brisard@gmail.com
In-Reply-To: <4E572E72.80001@gmail.com>
References: 
 <CAGRH7HpOHY6CSy584podiApoy45souvureSZsX6pNeyi-GtOSw@mail.gmail.com>
	<4E572E72.80001@gmail.com>
Date: Fri, 26 Aug 2011 08:15:15 +0200
Message-ID: 
 <CAGRH7HqoQYBCDYYFQhz_f3g9H7jh2OExUaU3vaSJ6e_32uYi5w@mail.gmail.com>
Subject: Re: [math] Consistent use of ExceptionContext [was "using the
 ExceptionContext facility"]
From: =?ISO-8859-1?Q?S=E9bastien_Brisard?= <sebastien.brisard@m4x.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

>
> One thing that I think we all agree on; however, is that we should not be
> designing exceptions or APIs that throw exceptions with the intent that
> applications catching exceptions should parse the messages or search
> the message content for specific strings.
>
I do apologize, I am not sure I fully understand. Please let me try
again. I agree, parsing e.getMessage() would be horrible, but that was
not what I had in mind.

Let's say that a NonPositiveDefiniteLinearOperatorException e is
raised, and I want to retrieve the operator in question. One way to do
it would be to have a getter
e.getOffendingLinearOperator()
In MATH-581, following the discussion entitled "Implementation of
Conjugate Gradient (MATH-581)" (started aug, 4), we finally went for
the more flexible
e.getContext().getValue("offending operator")

The issue then is a proper handling of the key names ("offending
operator" in the present case). Should the key names be assigned
arbitrarily by the method which throws the exception, or stored (as a
constant String) in the exception itself. My point is that in some
circumstances, it is possible to have the exception store "typical"
keys, which can be consistently used by everyone throwing such an
exception, with the further possibility to add supplementary context
to this exception, with freely chosen key names.

Is it what you understood from my previous message?
Best regards,
S=E9bastien

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