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 (athena.apache.org: domain of turingatemyhamster@gmail.com
 designates 209.85.212.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGRH7HoisCdiU8ZrxzG83UW7cemO4FiBAVONz7MM72iAZTWzbg@mail.gmail.com>
References: 
 <CAGRH7HpOHY6CSy584podiApoy45souvureSZsX6pNeyi-GtOSw@mail.gmail.com>
	<4E572E72.80001@gmail.com>
	<CAGRH7HqoQYBCDYYFQhz_f3g9H7jh2OExUaU3vaSJ6e_32uYi5w@mail.gmail.com>
	<20110826104555.GA16332@dusk.harfang.homelinux.org>
	<CAGRH7Hr=9Ae7tbP1DHmAy3xcARJa66n5fGQNJu+xtJ27oB_yuQ@mail.gmail.com>
	<20110826120530.GB16332@dusk.harfang.homelinux.org>
	<CAGRH7HoisCdiU8ZrxzG83UW7cemO4FiBAVONz7MM72iAZTWzbg@mail.gmail.com>
Date: Fri, 26 Aug 2011 14:44:35 +0100
Message-ID: 
 <CAHQS_exgOeoE6vp5cCiKUJqHju7bw_T6ueJAVfLZUe-FAXnW=Q@mail.gmail.com>
Subject: Re: [math] Consistent use of ExceptionContext [was "using the
 ExceptionContext facility"]
From: Matthew Pocock <turingatemyhamster@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=bcaec547cc2bf3169704ab68be2a

--bcaec547cc2bf3169704ab68be2a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

2011/8/26 S=E9bastien Brisard <sebastien.brisard@m4x.org>

>
> In other words, having this kind of context with documented keys would
> help the end-user debug his own code. I hope I'm making my point
> clearly, there.
>

More info attached to exceptions is great. I often find that the first half
of fixing a bug is adding more explicit exception throw/catch handling and
ever-more explicit messages, chasing the fault back to a root cause.
However, you have to ask who is going to be making use of the exception. Is
it someone who is debugging the library, or some user who's called into it
and somehow got broken behaviour?

For debugging, you are familiar with your own library, and can capture info
about the state around where the exception was raised using your IDE in
debug mode. Your users aren't familiar with the library, and should be able
to tell from the exception message if it is most likely their fault (and if
so, how to fix it), or the library's (in which case they may send you the
stack-trace and we all know that better annotated exceptions make it easier
to interpret these even across different builds).

So, personally I would lean on the side of as much explicit info in the
message as possible. "It was parameter A that borked me because it was XXX
and I was expecting YYY". Don't rely upon line numbers, because these chang=
e
as ppl edit the file and your users can understand 'A is borked' but can't
understand a line number. I wouldn't usually bother putting objects
capturing state describing the faulty environment into the exception as I
can get that from the debugger, given a test case. In my experience, a good
proportion of the real causes of exceptions aren't co-located with where th=
e
exception is raised. Perhaps with the right cascades of exception handlers,
all of which capture their relevant local state, you can then serialize the
result out and have a pre-canned test-case for the failure. I'm not sure ho=
w
practical this would be in the real world - I expect you'd drown in
try/catch eventualities. You may be better logging the hinkey state very
close to where the exception is raised rather than storing references to it=
.

Happy to be proved wrong though. Perhaps this is the beginning of an era of
code that spits out bug unit tests when ever there are exceptions.

Matthew


> Best regards,
> S=E9bastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


--=20
Dr Matthew Pocock
Visitor, School of Computing Science, Newcastle University
mailto: turingatemyhamster@gmail.com
gchat: turingatemyhamster@gmail.com
msn: matthew_pocock@yahoo.co.uk
irc.freenode.net: drdozer
tel: (0191) 2566550
mob: +447535664143

--bcaec547cc2bf3169704ab68be2a--