[Python-ideas] Make return inside a finally a SyntaxError

[Michael Foord]

2009/7/18 Terry Jones <terry at jon.es>

> I agree that having finally subsume returns and exceptions in the try block
> will at first be surprising to people, and that it can lead to
> easy-to-create
> but difficult-to-find bugs.
>
> But I think the current behavior is definitely for the best:
>
> - It's dead simple. The finally clause is always done last, and is always
>  responsible for the return of the function *no matter what* may have
>  happened in the try clause.



Finally is normally dead simple but the explanation usually includes what it
does with exceptions:

Finally is *always* run last. Exceptions that occur in the try block are
re-raised once the finally has completed. Exceptions inside the finally
block will be re-raised

The bit that has to be *added* in Python (and usually isn't added because it
isn't at all obvious) is:

Exceptions are not reraised if the finally returns or breaks.


>
>
> - If finally were to automatically propagate any exception from the try
>  clause, how would you turn that off when you needed/wanted to? You'd soon
>  wind up wanting another keyword, perhaps seriouslyfinally, that was
>  guaranteed to be run at the very end.



No, you'd use the already present and obvious except where you have the
*choice* of re-raising or ignoring the exception.


>
>
>  If finally propagated exceptions,


It does.


> what should it do if there's an
>  exception raised in the finally block?


It re-raises it on exit (except for two special cases - return and break).
Try it.


>  It begins to get complicated.




No, it gets simpler - no special cases for the exception handling of finally
in the presence of a return.

Michael


>
>  The primitive blanket solution is better, IMO.
>
> - Besides, if you do want a finally clause to propagate an exception from
>  its try clause, that's simple as you can just store the exception
>  somewhere in an except clause and then let the finally detect it and
>  re-raise it, if appropriate.
>
> By keeping finally's semantics simple and resisting the temptation to make
> it more sophisticated (e.g., propagating exceptions or return values) you
> wind up with a better tool for the programmer who does know what they're
> doing. The more sophisticated behavior can easily be added as you need it
> on a case-by-case basis. The added functionality shouldn't be provided
> unconditionally by the language because you then can't disable it.  I.e., I
> prefer the control I get from the current semantics of finally.
>
> Terry
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090718/a579aa05/attachment.html>