Hello. > > 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.
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
