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: Fri, 26 Aug 2011 16:14:27 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] Consistent use of ExceptionContext [was "using the
 ExceptionContext facility"]
Message-ID: <20110826141427.GC16332@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
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>
 <CAHQS_exgOeoE6vp5cCiKUJqHju7bw_T6ueJAVfLZUe-FAXnW=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAHQS_exgOeoE6vp5cCiKUJqHju7bw_T6ueJAVfLZUe-FAXnW=Q@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.

> 
> 2011/8/26 S�bastien 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 change
> as ppl edit the file and your users can understand 'A is borked' but can't
> understand a line number.

That's what is usually done when raising an exception: an explicit message
contains the direct cause of the failure.
What we discuss is how to propagate information that sometimes does not fit
into a string message.

> 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 the
> 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 how
> 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.

In the case under consideration, logging the state is not an option, I
think, because the default string representation of the operator might not
be interesting and/or the full state might be too large.
Thus the "manual" extraction which a knowledgeable user will control to
save the state to an appropriate output.

[Moreover, there is no logging in CM...]

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

At least, with the exception context, you can have access to the cause of
the failure, and make a test out of it.

Regards,
Gilles

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