raise None
Cameron Simpson
cs at zip.com.au
Thu Dec 31 00:45:03 EST 2015
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>
More information about the Python-list
mailing list