raise None

[Oscar Benjamin]

On 31 Dec 2015 15:54, "Chris Angelico" <rosuav at gmail.com> wrote:
>
> On Fri, Jan 1, 2016 at 2:35 AM, Steven D'Aprano <steve at pearwood.info>
wrote:
> >> If the user
> >> can see the stack trace and work back to the point where they passed
> >> something in to your function then how does the extra level hurt?
> >
> > It hurts precisely because it is one extra level. I acknowledge that it
is
> > *only* one extra level. (I told you this was a marginal benefit.)
> >
> > If one extra level is okay, might two extra be okay? How about three?
What
> > about thirty? Where would you draw the line?
> >
>
> It becomes something to get used to when you work with a particular
> library. Several of my students have run into this with matplotlib or
> sklearn; you make a mistake with a parameter to function X, which just
> takes that as-is and passes it to function Y, which does some
> manipulation but doesn't trip the error, and then calls through to
> function Z, which notices that one parameter doesn't match another,
> and raises an exception. You get used to scrolling way up to find the
> actual cause of the error

Exactly. The critical technique is looking at the traceback and splitting
it between what's your code and what's someone else's. Hopefully you don't
need to look at steves_library.py to figure out what you did wrong. However
if you do need to look at Steve's code you're now stumped because he's
hidden the actual line that raises. All you know now is that somewhere in
_validate the raise happened. Why hide that piece of information and
complicate the general interpretation of stack traces?

Actually matplotlib is a particularly tricky case as often the arguments
you pass or stored and not accessed until later. So the traceback shows an
error in the call to show() rather than e.g. legend(). Usually I can glean
pretty quickly that e.g. the legend labels are at fault though from the
traceback though.

--
Oscar