raise None

Steven D'Aprano steve at pearwood.info
Wed Dec 30 23:07:53 EST 2015


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.

 

-- 
Steven




More information about the Python-list mailing list