commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Consistent use of ExceptionContext [was "using the ExceptionContext facility"]
Date Fri, 26 Aug 2011 14:14:27 GMT

> 2011/8/26 Sébastien Brisard <>
> >
> > 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message