Lars Yencken <[email protected]> writes: > On 5 September 2013 14:48, Ben Finney <[email protected]> wrote: > > Why is it a problem for the exception to be raised within the bowels > > of your program? I'm not saying there can't be a reason, but you > > haven't said what the problem is. > > > > In many cases, it is quite helpful that the bowels of your program > > is where you want the exception raised from. Without knowing what > > trouble this causes you, I don't know what to say. > > I'll give two examples: > > 1. Large batch scientific jobs, where you might encounter a runtime error > after 30 mins (or worse, hours) of partial computation.
Right. This is an argument for capturing errors at a high level, and reporting them with high-level context. > 2. Unicode, unicode, unicode. If you've had to debug code which > accepted a mix of strings and unicode, you'll know what a pain it is > to get a unicode error deep in the bowels of your app -- essentially > the stacktrace is useless, it doesn't explain well enough how the > error got there. Isn't the exact function of a call stack to show in detail how the interpreter got to the point of an exception? What information about “how it got there” are you expecting that isn't provided by a stack trace? > By capturing assumptions about the input at the border of your stack, > instead of throughout it, you can save yourself a lot of pain. Yes. Again, this is an argument for capturing errors at a high enough level to provide context. Neither of these is an argument for doing type checking deep within the code, as you seemt o advocate. Instead, these are arguments for allowing low-level exceptions to propagate up to the caller until they reach a point of responsibility where there is enough context to handle the exception. -- \ “The generation of random numbers is too important to be left | `\ to chance.” —Robert R. Coveyou | _o__) | Ben Finney _______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
