raise None

[Steven D'Aprano]

On Thu, 31 Dec 2015 03:03 pm, Cameron Simpson wrote:

[...]
Steven D'Aprano (that's me) wrote this:
>>Whereas if _validate does what it is supposed to do, and is working
>>correctly, you will see:
>>
>>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.
> 
> Would it not be useful then to name the including function in the
> exception text?

You mean change the signature of _validate to:

def _validate(a, b, name_of_caller):
    ...

and have function "other" call it like this:

def other(arg1, arg2):
    _validate(arg1, arg2, "other")
    # if we reach this line, the arguments were validated 
    # and we can continue
    ...


I think that's pretty horrible. I'm not sure whether that would be more, or
less, horrible than having _validate automagically determine the caller's
name by looking in the call stack.


[...]
> I confess that when I want to check several things I would like to return
> several failure indications. So thing on that line, how about this:
> 
>   for blam in _validate(a, b):
>     raise blam
> 
> which leaves you open to gatheroing them all up instead of aborting on the
> first complaint.

Are you sure? I would have expected that raising the first exception would
exit the loop.


>>I think this is a win for debuggability. (Is that a word?) But it's a bit
>>annoying to do it today, since you have to save the return result and
>>explicitly compare it to None. If "raise None" was a no-op, it would feel
>>more natural to just say raise _validate() and trust that if _validate
>>falls out the end and returns None, the raise will be a no-op.
> 
> This is a nice idea though. Succinct and expressive, though people would
> have to learn that:
> 
>   raise foo()
> 
> does not unconditionally abort at this point.

Yes, that crossed my mind. Maybe if there was a second keyword:

    raiseif foo()

which only raised if foo() returned a non-None value. That's kind of like
the "or die" idiom from Perl, I guess. But of course requiring a second
keyword will almost certainly doom this proposal -- it is only of benefit
at the margins as it is.



-- 
Steven