歴史: PEP 343 は Python 2.5 で with 文を導入し、以前は冗長な手動の try-finally ブロックが必要だったリソース管理パターンを標準化しました。このプロトコルは、オブジェクトが __enter__ と __exit__ メソッドを実装することを要求し、重要な革新は __exit__ が例外を検査し、必要に応じてその戻り値により抑制できる能力です。この設計により、インフラストラクチャがビジネスロジックに伝播させずに期待される失敗を処理できる優雅な劣化パターンが可能になります。
問題: with ブロック内で例外が発生すると、Python はアクティブな例外の詳細を持つ __exit__(exc_type, exc_val, exc_tb) を呼び出します。このメソッドが真の値（真偽コンテキストで True と評価される）を返すと、Python は例外が処理されていると見なし、伝播を完全に抑制します。 False、None、またはその他の偽の値を返すと、クリーンアップが成功したかどうかに関係なく、例外は通常通り伝播します。
解決策: __exit__ を実装して、例外が意図的に抑制されるべき場合にのみ True を返します。たとえば、期待される検証エラーや一時的なネットワーク障害などです。クリーンアップが完了したが、エラーが伝播すべき場合には False を明示的に返すか、メソッドの最後で落ちて None を暗黙的に返します。このメソッドはアクティブな例外を説明する三つの引数を受け取ります。正常に終了する場合は (None, None, None) です。
class SuppressKeyError: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): if exc_type is KeyError: print(f"Swallowed: {exc_val}") return True # 抑制 return False # 他を伝播 # 使用法 with SuppressKeyError(): raise KeyError("ignored") # 無音 with SuppressKeyError(): raise ValueError("propagated") # 発生
シナリオ: 開発チームが分散タスクプロセッサを構築し、ワーカーノードが重要なセクションを実行する前に Redis を介して排他ロックを取得します。ネットワークの遅延が LockTimeout例外を引き起こすと、システムはワーカープロセスがクラッシュすることなく透明に再試行する必要があります。ただし、MemoryError のような致命的なエラーやプログラミングミスは、アラートをトリガーして無限再試行ループを防ぐために直ちに伝播される必要があります。
問題: 最初の実装はビジネスロジック全体に散在する try-except ブロックを持っており、メンテナンスの悪夢を引き起こし、実際のドメインコードを不明瞭にしました。この選択的抑制メカニズムをドメインコードを汚染することなく集中化することが課題です。
解決策 1: 明示的にネストされた try-except ブロックで各タスク実行をラップします。 利点: コントロールフローはビジネスロジックの読者にとってすぐに見えるため、新しいチームメンバーのデバッグが容易です。 欠点: このアプローチは再試行ロジックを至る所で繰り返すことになり、ビジネスコードをインフラストラクチャの詳細に強く結びつけ、ユニットテストを難しくします。テストは、ロックの失敗を毎回の呼び出しサイトでシミュレートしなければならないためです。
解決策 2: DumbSuppressor コンテキストマネージャを作成し、常に __exit__ から True を返します。
利点: 実装はわずか2行のコードを必要とし、ビジネスロジックからの例外処理のボイラープレートを完全に排除します。
欠点: すべての例外、特に重要なシステムエラーやプログラミングバグを危険にさらすため、静かな失敗や未定義のアプリケーション状態を引き起こし、製品環境でのデバッグが不可能になります。
解決策 3: SmartRetryContext を実装し、exc_type を一時的な例外の構成可能なホワイトリストと照合します。
利点: これにより、再試行ロジックが宣言的に集中化され、どのエラーが再試行を引き起こすかを正確に制御し、ビジネスロジックとインフラストラクチャの懸念事項の間にきれいな分離を維持します。
欠点: ホワイトリストは慎重になる必要があり、予期せぬエラーが一時的なインフラストラクチャの問題ではなく、本物のバグであることを示さないようにしなければなりません。
選択したアプローチ: チームは安全性と機能性のバランスが取れた解決策3を選択しました。 __exit__ メソッドは issubclass(exc_type, RetriableException) をチェックし、ネットワークタイムアウトのような一時的な障害に対してのみ True を返しますが、プログラミングエラーは直ちに表面化します。
結果: システムは Redis の遅延スパイクを自動的に再試行して優雅に処理しますが、バグがある場合には適切にクラッシュします。モニタリングダッシュボードは、一時的な失敗からのアラートノイズが40％削減されたことを示し、開発者はロック取得の詳細を気にせずにタスクロジックを書くことができました。
質問: Python の __exit__ メソッドが None を返す場合と、False を返す場合の挙動の違いは何か、そしてなぜ両方とも例外の伝播をもたらすのか、None が偽であるにもかかわらず？
回答. 多くの候補者は、None を返すことが「意見なし」を示し、False が積極的に伝播を要求することを誤って信じています。Python では、両方の値は真偽コンテキストで偽であり、プロトコルは明示的に if not exit_return_value: propagate_exception() をチェックします。したがって、None と False は同じように動作します—どちらの場合も例外が伝播します。この違いはコードの可読性のみ重要です。False は意図的な伝播を示し、None は偶発的な省略を示します。
質問: Python の __exit__ メソッドが意図的に True を返して例外を抑制しても、その後、クリーンアップロジックの中で新しい例外が発生した場合、どの例外が外側のスコープに伝播するかは何によって決まりますか？
回答. __exit__ で発生した新しい例外は、元の例外を完全に置き換えます。Python は最初に __exit__ の戻り値を評価します。真の場合、元の例外を抑制する準備をします。ただし、__exit__ 自体が戻る前に例外を発生させた場合、その新しい例外が代わりに伝播し、元の例外は明示的に raise NewException from original を使用してチェーンしない限り失われます。これは finally ブロックとは異なり、finally ブロック内の例外は置き換えられるがアクティブな例外とチェーンできる可能性があります。
質問: Python は、__enter__ が入った後でも __exit__ が呼び出されないことを保証する条件は何であり、これは finally ブロックの保証とどのように異なりますか？
回答. __enter__ が例外を発生させた場合、Python は __exit__ を決して呼び出しません。なぜなら、コンテキストは正常に確立されなかったからです。これは、try-finally のセマンティクスとは大きく対照的で、try スイートが入る直後に例外を発生させても finally ブロックは実行されます。この違いはリソース管理にとって重要であり、失敗時に __enter__ 内で部分的に割り当てられたリソースは、__exit__ がそれらをクリーンアップするために実行されないため、__enter__ 自体の中で try-finally を使用してクリーンアップする必要があります。