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
--
https://mail.python.org/mailman/listinfo/python-list
