raise None

[Oscar Benjamin]

On 31 December 2015 at 04:07, Steven D'Aprano <steve at pearwood.info> wrote:
> On Thu, 31 Dec 2015 12:44 pm, Ben Finney wrote:
>
>> Steven D'Aprano <steve at pearwood.info> writes:
>>
>>> Traceback (most recent call last):
>>>   File "spam", line 19, in this
>>>   File "spam", line 29, in that
>>>   File "spam", line 39, in other
>>>   File "spam", line 5, in _validate
>>> ThingyError: ...
>>>
>>> and the reader has to understand the internal workings of _validate
>>> sufficiently to infer that this exception is not a bug in _validate
>>> but an expected failure mode of other when you pass a bad argument.
>>
>> This point seems to advocate for suppressing *any* code that
>> deliberately raises an exception. Is that your intent?
>
> No. The issue isn't that an exception is deliberately raised. The issue is
> that it is deliberately raised in a function separate from where the
> exception conceptually belongs. The exception is conceptually part of
> function "other", and was only refactored into a separate function
> _validate to avoid repeating the same validation code in multiple places.
> It is a mere implementation detail that the exception is actually raised
> inside _validate rather than other.
>
> 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. 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. 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?

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)

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.

--
Oscar