Hi, 2011/8/26 Sébastien Brisard <sebastien.bris...@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. 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. Matthew > Best regards, > Sébastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Dr Matthew Pocock Visitor, School of Computing Science, Newcastle University mailto: turingatemyhams...@gmail.com gchat: turingatemyhams...@gmail.com msn: matthew_poc...@yahoo.co.uk irc.freenode.net: drdozer tel: (0191) 2566550 mob: +447535664143
