Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #101042

Re: raise None

From Cameron Simpson <cs@zip.com.au>
Newsgroups comp.lang.python
Subject Re: raise None
Date 2015-12-31 16:45 +1100
Message-ID <mailman.101.1451540708.11925.python-list@python.org> (permalink)
References <5684b94d$0$1586$c3e8da3$5496439d@news.astraweb.com>

Show all headers | View raw


On 31Dec2015 16:12, Steven D'Aprano <steve@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@zip.com.au>

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

raise None Steven D'Aprano <steve@pearwood.info> - 2015-12-31 11:09 +1100
  Re: raise None Paul Rubin <no.email@nospam.invalid> - 2015-12-30 16:19 -0800
  Validation in Python (was: raise None) Ben Finney <ben+python@benfinney.id.au> - 2015-12-31 11:26 +1100
  Re: raise None Chris Angelico <rosuav@gmail.com> - 2015-12-31 11:38 +1100
    Re: raise None Steven D'Aprano <steve@pearwood.info> - 2015-12-31 12:26 +1100
      Re: raise None Ben Finney <ben+python@benfinney.id.au> - 2015-12-31 12:44 +1100
        Re: raise None Steven D'Aprano <steve@pearwood.info> - 2015-12-31 15:07 +1100
          Re: raise None Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-12-31 12:19 +0000
            Re: raise None Steven D'Aprano <steve@pearwood.info> - 2016-01-01 02:35 +1100
              Re: raise None Chris Angelico <rosuav@gmail.com> - 2016-01-01 02:53 +1100
              Re: raise None Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-12-31 16:46 +0000
                Re: raise None Steven D'Aprano <steve@pearwood.info> - 2016-01-01 04:50 +1100
              Re: raise None "Martin A. Brown" <martin@linux-ip.net> - 2015-12-31 09:30 -0800
              Re: raise None Ben Finney <ben+python@benfinney.id.au> - 2016-01-01 07:18 +1100
                Re: raise None Johannes Bauer <dfnsonfsduifb@gmx.de> - 2016-01-02 12:47 +0100
              Re: raise None Chris Angelico <rosuav@gmail.com> - 2016-01-01 09:48 +1100
                Re: raise None Steven D'Aprano <steve@pearwood.info> - 2016-01-04 16:19 +1100
                Re: raise None Dan Sommers <dan@tombstonezero.net> - 2016-01-04 06:09 +0000
                Re: raise None Rustom Mody <rustompmody@gmail.com> - 2016-01-03 22:39 -0800
              Re: raise None Ben Finney <ben+python@benfinney.id.au> - 2016-01-01 10:27 +1100
                Re: raise None Marko Rauhamaa <marko@pacujo.net> - 2016-01-01 02:29 +0200
                Re: raise None Steven D'Aprano <steve@pearwood.info> - 2016-01-04 16:19 +1100
                Re: raise None Rustom Mody <rustompmody@gmail.com> - 2016-01-03 21:53 -0800
                Re: raise None Rustom Mody <rustompmody@gmail.com> - 2016-01-04 03:55 -0800
                Re: raise None Rustom Mody <rustompmody@gmail.com> - 2016-01-03 21:53 -0800
              Re: raise None Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-12-31 23:36 +0000
              Re: raise None Chris Angelico <rosuav@gmail.com> - 2016-01-01 10:39 +1100
              Re: raise None Chris Angelico <rosuav@gmail.com> - 2016-01-01 10:41 +1100
              Re: raise None Rustom Mody <rustompmody@gmail.com> - 2016-01-03 19:04 -0800
                Re: raise None Chris Angelico <rosuav@gmail.com> - 2016-01-04 14:31 +1100
                Re: raise None Steven D'Aprano <steve@pearwood.info> - 2016-01-04 14:48 +1100
                Re: raise None Chris Angelico <rosuav@gmail.com> - 2016-01-04 14:56 +1100
                Re: raise None Rustom Mody <rustompmody@gmail.com> - 2016-01-03 20:46 -0800
              Re: raise None Christian Gollwitzer <auriocus@gmx.de> - 2016-01-04 08:28 +0100
      Re: raise None Chris Angelico <rosuav@gmail.com> - 2015-12-31 13:12 +1100
      Re: raise None Cameron Simpson <cs@zip.com.au> - 2015-12-31 15:03 +1100
        Re: raise None Steven D'Aprano <steve@pearwood.info> - 2015-12-31 16:12 +1100
          Re: raise None Cameron Simpson <cs@zip.com.au> - 2015-12-31 16:45 +1100
  Re: raise None Terry Reedy <tjreedy@udel.edu> - 2015-12-30 23:00 -0500
  Re: raise None Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-12-31 15:58 +0000
  Re: raise None Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-12-31 17:17 +0100

csiph-web