raise None

[Steven D'Aprano]

On Thu, 31 Dec 2015 11:19 pm, Oscar Benjamin wrote:

> On 31 December 2015 at 04:07, Steven D'Aprano <steve at pearwood.info> wrote:
[...]
>> As an implementation detail, exposing it to the user (in the form of a
>> line in the stacktrace) doesn't help debugging. At best it is neutral
>> (the user reads the error message and immediately realises that the
>> problem lies with bad arguments passed to other, and _validate has
>> nothing to do with it). At worst it actively misleads the user into
>> thinking that there is a bug in _validate.
> 
> You're overthinking this.

Maybe. As I have suggested a number of times now, I'm aware that this is
just a marginal issue.

But I think it is a real issue. I believe in beautiful tracebacks that give
you just the right amount of information, neither too little nor two much.
Debugging is hard enough with being given more information than you need
and having to decide what bits to ignore and which are important.

(Aside: does anyone else hate the tracebacks given by PyCharm? We've had a
number of people posting traceback of errors from PyCharm recently, and in
my opinion they drown you in irrelevant detail.)


> It's fine for the error to come from 
> _validate. Conceptually the real error is not in _validate or the
> function that calls _validate but in whatever function further up the
> stack trace created the wrong type of object to pass in.

That may be so, but that could be *anywhere* in the call chain. The ultimate
cause of the error may not even appear in the call chain.

The principle is that errors should be raised as close to their cause as
possible. If I call spam(a, b) and provide bad arguments, the earliest I
can possibly detect that is in spam. (Only spam knows what it accepts as
arguments.) Any additional levels beyond spam (like _validate) is moving
further away:

  File "spam", line 19, in this
  File "spam", line 29, in that      <--- where the error really lies
  File "spam", line 39, in other
  File "spam", line 89, in spam      <--- the first place we could detect it
  File "spam", line 5, in _validate  <--- where we actually detect it


> 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?

 
> If it really bothers you then you can use a comment that will show up
> in the traceback output
> 
>     _validate(a, b) # Verify arguments to myfunc(a, b)

No, that can't work. (Aside from the fact that in the most general case, the
source code may no longer be available to read.) The whole point of moving
the validation code into a function was to share it between a number of
functions.


> but really I don't think it's a big deal. The traceback gives you
> useful information about where to look for an error/bug but it's still
> the programmer's job to interpret that, look at the code, and try to
> understand what they have done to cause the problem.

Sure. And I believe that this technique will make the programmer's job just
a little bit easier.



-- 
Steven