This is intended behavior. If a finally clause does anything else
than reach its end without problems, that action takes precedence and
completely masks the exception (or non-exception) that was held.
In this way, if the exception raised by the finally clause was caused
by a programming error, and presuming it is not masked in turn by a
too generous outer except clause, the point of the error in the
finally clause shows up in the stack trace, as it should.
Note that "break" and "return" are implemented as pseudo-exceptions.
Not only does this save machinery but also does it give an
understandable semantic model. I stole this idea from Modula-3, like
most of the exception stuff in Python. As far as I can tell M3 has
the same semantics as Python in the situation you describe.
Finally note that the source of your conclusion may be a different
model of how exceptions work. The raised exception is not "directed"
at the outer except clause -- it is simply an alternate return from
the function, which percolates through the stack until a matching
exception handler is found. When a finally clause is executed, the
pending exception is temporarily saved, and when the finally clause
completes normally the saved exception is re-raised.
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>