Why Your Python with‑Statement Fails: Debugging Global Process Locks

Problem Origin

Earlier I implemented a global process lock using a with statement, relying on Redis SETNX and adding measures for cache penetration and delayed retries.

Unit tests initially passed, giving the impression that the lock worked correctly.

The lock was implemented by raising an exception in __enter__ and catching it in __exit__:

However, this approach is flawed because __exit__ is not wrapped around __enter__; therefore, exceptions raised in __enter__ are not caught by __exit__. The original unit tests passed only because the outer with caught the inner __enter__ exception.

When the improved unit test is used, the tests fail:

The same issue appeared in an AB‑testing scenario where __enter__ raised an exception and __exit__ attempted to catch it, but the exception prevented __enter__ from executing.

First Solution

Understanding the execution order of with, the first solution adds a helper function to confirm the exception after __enter__ completes, modifying ABContext accordingly:

Usage example:

This approach is not very elegant; forgetting to call the helper method defeats the purpose and reduces Pythonic readability.

Second Solution

Reviewing the contextlib documentation reveals the now‑deprecated contextlib.nested function, which allowed multiple contexts to be entered together:

In Python 2.7 and later, the same effect can be achieved with a single with statement:

By arranging the contexts so that the first context's __exit__ catches the exception and the second context's __enter__ raises it, we can implement the desired behavior:

Integrating this with the existing ABContext yields passing unit tests:

Third Solution

A simpler workaround uses a plain if statement to handle the exception within the same indentation block:

TIL

In summary, I learned useful functions and decorators from contextlib, discovered that a with statement can contain another context, and realized that dynamically constructing multiple contexts still requires further research; a with block cannot directly accept a tuple or list.