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