commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Pocock <>
Subject Re: [math] Consistent use of ExceptionContext [was "using the ExceptionContext facility"]
Date Fri, 26 Aug 2011 13:44:35 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. 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.

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.


> Best regards,
> S├ębastien
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Dr Matthew Pocock
Visitor, School of Computing Science, Newcastle University
msn: drdozer
tel: (0191) 2566550
mob: +447535664143

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message