raise None

[Cameron Simpson]

On 31Dec2015 16:12, Steven D'Aprano <steve at pearwood.info> wrote:
>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.

No, I meant your latter suggestion above: consult the call stack to fish out 
the calling function name.  Something like:

  from cs.py.stack import caller
  ...
  def _validate(...):
    frame = caller()
    funcname = frame.functionname

and then use funcname in the messages, or greater detail. Caller() is available 
here:

  https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/py/stack.py?fileviewer=file-view-default

for the fiddliness. The horribleness is at least concealed, unless you're 
nesting _validate implementations.

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

In the bare form, surely, just like your "if". But in principle you could 
gather all the exceptions together and raise a new exception with details 
attached.

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

I'd rather your original myself: plain "raise". Another keyword seems a reach, 
and I don't like it. And I don't like "raiseif"; I've got a bunch of "blahif" 
functions of similar flavour and I'm stuff unhappy with their names.

I think it is a small thing to learn, especially as "raise None" is already an 
error.

Cheers,
Cameron Simpson <cs at zip.com.au>