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


Groups > comp.lang.python > #65169

Re: Try-except-finally paradox

From Göktuğ Kayaalp <self@gkayaalp.com>
Subject Re: Try-except-finally paradox
References <9314ac52-a2be-4382-94ef-2c291f32be1a@googlegroups.com> <lcdf0c$bnl$2@ger.gmane.org> <lcfc58$bep$1@ger.gmane.org>
Date 2014-02-01 03:58 +0200
Newsgroups comp.lang.python
Message-ID <mailman.6247.1391223064.18130.python-list@python.org> (permalink)

Show all headers | View raw


Terry Reedy <tjreedy@udel.edu> writes:

I do not have any information on the topic, but I *imagine* that the
when RETURN_VALUE opcode is evaluated within the context of an except
block, it triggers a check for whether a corresponding finally block
exists and should it exist, it is triggered, much like a callback.
So, my *imaginary* algorithm works like this:

return:
  if within an except block EB:
    if EB has a correspoinding final block FB
      run FB
    else
      do return
  else
    do return

In Jessica's example, as the finally block executes a RETURN_VALUE
opcode, and as this is *probably* a jump to the caller, the rest of the
code does not get a chance to be executed.

As I have said earlier, I by no means assert the truth of this idea I've
explained here, but it seems quite reasonable to me.

          gk

> On 1/30/2014 7:05 AM, Dave Angel wrote:
>>   Jessica Ross <deathweasel@gmail.com> Wrote in message:
>>> I found something like this in a StackOverflow discussion.
>>>>>> def paradox():
>>> ...     try:
>>> ...             raise Exception("Exception raised during try")
>>> ...     except:
>>> ...             print "Except after try"
>>> ...             return True
>>> ...     finally:
>>> ...             print "Finally"
>>> ...             return False
>>> ...     return None
>>> ...
>>>>>> return_val = paradox()
>>> Except after try
>>> Finally
>>>>>> return_val
>>> False
>>>
>>> I understand most of this.
>>> What I don't understand is why this returns False rather than True. Does the finally short-circuit the return in the except block?
>>>
>>
>> The finally has to happen before any return inside the try or the
>>   except.  And once you're in the finally clause you'll finish it
>>   before resuming the except clause.  Since it has a return,  that
>>   will happen before the other returns. The one in the except block
>>   will never get reached.
>>
>> It's the only reasonable behavior., to my mind.
>
> Checking with the disassembled code, it appears that the except return
> happens first and is then caught and the value over-written
>
>   2           0 SETUP_FINALLY           45 (to 48)
>               3 SETUP_EXCEPT            16 (to 22)
>
>   3           6 LOAD_GLOBAL              0 (Exception)
>               9 LOAD_CONST               1 ('Exception raised during try')
>              12 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
>              15 RAISE_VARARGS            1
>              18 POP_BLOCK
>              19 JUMP_FORWARD            22 (to 44)
>
>   4     >>   22 POP_TOP
>              23 POP_TOP
>              24 POP_TOP
>
>   5          25 LOAD_GLOBAL              1 (print)
>              28 LOAD_CONST               2 ('Except after try')
>              31 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
>              34 POP_TOP
>
>   6          35 LOAD_CONST               3 (True)
>              38 RETURN_VALUE
>              39 POP_EXCEPT
>              40 JUMP_FORWARD             1 (to 44)
>              43 END_FINALLY
>         >>   44 POP_BLOCK
>              45 LOAD_CONST               0 (None)
>
>   8     >>   48 LOAD_GLOBAL              1 (print)
>              51 LOAD_CONST               4 ('Finally')
>              54 CALL_FUNCTION            1 (1 positional, 0 keyword pair)
>              57 POP_TOP
>
>   9          58 LOAD_CONST               5 (False)
>              61 RETURN_VALUE
>              62 END_FINALLY
>
>  10          63 LOAD_CONST               0 (None)
>              66 RETURN_VALUE
>
>
>
>
> -- 
> Terry Jan Reedy

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


Thread

Try-except-finally paradox Jessica Ross <deathweasel@gmail.com> - 2014-01-29 21:56 -0800
  Re: Try-except-finally paradox Ian Kelly <ian.g.kelly@gmail.com> - 2014-01-29 23:23 -0700
  Re: Try-except-finally paradox Andrew Berg <robotsondrugs@gmail.com> - 2014-01-30 00:33 -0600
    Re: Try-except-finally paradox Rotwang <sg552@hotmail.co.uk> - 2014-01-30 18:12 +0000
      Re: Try-except-finally paradox Ethan Furman <ethan@stoneleaf.us> - 2014-01-30 10:30 -0800
  Re: Try-except-finally paradox wxjmfauth@gmail.com - 2014-01-29 22:59 -0800
  Re:Try-except-finally paradox Dave Angel <davea@davea.name> - 2014-01-30 07:05 -0500
  Re: Try-except-finally paradox Chris Angelico <rosuav@gmail.com> - 2014-01-31 00:02 +1100
  Re: Try-except-finally paradox MRAB <python@mrabarnett.plus.com> - 2014-01-30 13:11 +0000
  Re: Try-except-finally paradox Chris Angelico <rosuav@gmail.com> - 2014-01-31 00:19 +1100
  Re: Try-except-finally paradox Terry Reedy <tjreedy@udel.edu> - 2014-01-31 00:26 -0500
  Re: Try-except-finally paradox Göktuğ Kayaalp <self@gkayaalp.com> - 2014-02-01 03:58 +0200

csiph-web