Try-except-finally paradox

[Chris Angelico]

On Thu, Jan 30, 2014 at 11:05 PM, Dave Angel <davea at davea.name> wrote:
> 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.

It's arguable that putting a return inside a finally is unreasonable
behaviour, but that's up to the programmer. A finally clause can be
used to do what might be done in C++ with a destructor: "no matter how
this function/block exits, do this as you unwind the stack". In C++, I
might open a file like this:

void func()
{
    ofstream output("output.txt");
    // do a whole lot of stuff ...
    // at the close brace, output.~output() will be called, which will
close the file
}

In Python, the equivalent would be:

def func():
    try:
        output = open("output.txt", "w")
        # do a whole lot of stuff ...
    finally:
        output.close()

(Actually, the Python equivalent would be to use a 'with' clause for
brevity, but 'with' uses try/finally under the covers, so it comes to
the same thing.) The concept of the finally clause is: "Whether
execution runs off the end, hits a return statement, or throws an
exception, I need you do this before anything else happens". Having a
return statement inside 'finally' as well as in 'try' is a bit of a
corner case, since you're now saying "Before you finish this function
and return something, I need you to return something else", which
doesn't usually make sense. If you think Python's behaviour is
confusing, first figure out what you would expect to happen in this
situation :)

ChrisA