非同期I/Oのエラーハンドリング構造をレビューで検証する技術
非同期I/Oのエラーハンドリング構造をレビューで検証する技術
Pythonにおけるasync/await構文は非同期I/O処理に強力な表現力を与えるが、例外の伝播や非同期タスクの失敗検知は同期処理とは異なる特性を持つ。
これに気づかず設計されたコードは、エラーを見逃したり、タスクが途中で失敗しても検出されないまま放置されるといった問題を引き起こす。
本マニュアルでは、非同期I/Oのエラー制御構造をレビューでどう読み解き、どこに設計的弱点があるかをどう指摘するかに焦点を当てて解説する。
async関数と例外伝播の基本動作
async def fetch_data():
raise ValueError("Invalid")
async def main():
await fetch_data()このコードは main() を asyncio.run(main()) で実行すれば ValueError を表層に伝播する。
つまり、awaitされた関数の中で発生した例外は、呼び出し元まで伝播するのが原則である。
@Reviewer: 非同期関数内部で発生する例外は、await側で適切に捕捉されていないと、上位コールスタックで処理不能になります。必要に応じてtry-exceptを設置すべきです。非同期関数の中でawaitされた処理が例外を発生した場合、それは通常のtry-exceptで捕捉できる。
ただし、非同期タスク群の同時実行（gather, create_taskなど）では、別の注意が必要となる。
典型的な見落とし1：gather内の例外処理
results = await asyncio.gather(task1(), task2(), task3())gatherは、いずれかのタスクが失敗するとその例外を上位に伝播するが、他のタスクがどうなったかは把握されないままになる。
@Reviewer: `asyncio.gather`の使用時は、どのタスクが失敗したか、成功結果がどこまで有効かが明示されていないため、戻り値の評価処理を分離すべきです。安全設計例
results = await asyncio.gather(task1(), task2(), task3(), return_exceptions=True)
for r in results:
if isinstance(r, Exception):
logger.error(f"Task failed: {r}")典型的な見落とし2：create_taskによる「握り潰し」
async def background():
raise RuntimeError("fail")
async def main():
asyncio.create_task(background())これは例外がログにも表示されず、握り潰されてしまう構造である。
レビューでは「そのタスクの成否を監視する設計があるか」を確認する。
@Reviewer: `create_task`で起動された処理の戻り値や例外が監視されておらず、実行失敗が無視されるリスクがあります。明示的なコールバックや監視構造を用意してください。create_taskによる例外放置の構造図
見逃しやすい構造3：非同期IOと同期コードの境界漏れ
async def process():
try:
await fetch_data()
except NetworkError:
handle_error()
def wrapper():
asyncio.run(process())この構造自体は正しいが、handle_errorが同期関数だった場合、そこで再びawaitを必要とする処理が呼ばれても動作しない可能性がある。
@Reviewer: エラー処理関数`handle_error`が同期関数のまま非同期I/Oを含むと、イベントループ制御が破綻します。処理文脈を一致させるよう再設計を検討してください。エラーハンドリング設計をレビューする上での5つの観点
| 観点 | 内容 | 優先度 |
|---|---|---|
| try-exceptの粒度 | どのレイヤでどのエラーを握るか明確か | 高 |
| gatherの使用法 | 複数タスクの失敗が正しく処理されているか | 高 |
| タスクの監視設計 | create_taskの戻り値を追跡・監視しているか | 高 |
| 非同期と同期の境界意識 | エラー処理が実行文脈に沿って整合しているか | 中 |
| エラー種別の明示 | 発生しうる例外が明示的にドキュメント or コードに記述されているか | 中 |
例外の種類を限定して捕捉しているか
try:
await fetch_from_api()
except Exception:
pass # すべてを無視このような構造は危険で、レビューでは例外種の明記とpassの理由説明を要求する。
@Reviewer: `except Exception:` によりすべての例外が握り潰されています。発生しうる例外を特定し、限定的に処理するようにしてください。適切なエラーハンドリング構造のサンプル
async def fetch_safe():
try:
return await fetch_data()
except NetworkError as e:
logger.warning(f"Network issue: {e}")
return None- 非同期処理は
await付きで明示 - エラー種別を限定
- ログで可観測性確保
- 戻り値で失敗状態を明示
まとめ：レビューアーは非同期の「失敗の伝播経路」を読む
非同期処理のエラーハンドリングは、同期構造とは異なるリスクを抱えており、レビューアーは単なるtry-exceptの有無ではなく、失敗がどこからどこへ伝播しているかを設計として読み解く必要がある。
失敗が握り潰されていないか。
失敗時にどこまでロジックが継続し、どこで停止すべきか。
レビューではこの“伝播の意図”に着目し、構造的な可視性を高めるコメントと指摘が求められる。