[Python-Dev] PEP 344: Explicit vs. Implicit Chaining

Michael Chermside mcherm at mcherm.com
Mon May 23 14:34:39 CEST 2005


James Knight writes:
> I still don't see why people think the python interpreter should be
> automatically providing __context__. To me it seems like it'll just
> clutter things up for no good reason. If you really want the other
> exception, you can access it via the local variable in the frame
> where it was first caught.

No you can't, because you didn't know the second exception was
going to happen! I write something like this:

    db_connection = get_db_connection()
    try:
        do_some_stuff(db_connection)
    except DatabaseException, err:
        log_the_problem(err)
        cleanup(db_connection)

If something goes wrong inside of do_some_stuff, I enter the
exception handler. But then if an error occurs within
log_the_problem() or cleanup(), then I lose the original exception.
It's just GONE. I didn't expect log_the_problem() or cleanup() to
fail, but sometimes things DO fail.

An example of this happens to me in in Java (which has the same
problem. I have code like this:

    db_connection = get_db_connection()
    try:
        do_some_stuff(db_connection)
    finally:
        db_connection.close()

For instance, when I want to do
unit testing, I create a mock database connection that raises
an exception if you don't use it as the test expects. So I get
exceptions like this all the time:

    Error: did not expect call to "close()"

Of course, what REALLY happened was that we tried to update a row
that didn't exist, which created an exception:

    Error: tried to update row with key "100", but it does not exist.

But then it entered the finally clause, and tried to close the
connection. That wasn't expected either, and the new exception
replaces the old one... and we lose information about what REALLY
caused the problem.

In Java, I had to fix this by making my mock objects very smart.
They have to keep track of whether any problem has occurred during
this test (in any of the cooperating mock objects) and if so, then
they have to re-report the original problem whenever something new
goes wrong. This is the only way I've found to work around the
problem in Java. Wouldn't it be nice if Python could do better?

-- Michael Chermside


More information about the Python-Dev mailing list