例外処理レビュー：try-exceptがロジックを隠す構造への対処法
はじめに
Pythonのtry-except構文は、エラーに対する堅牢性を実現する便利な手段である。
しかし、レビューアーの視点で見ると「例外処理がロジックそのものを隠してしまう設計」が頻繁に見受けられる。
特に、次のような構造はレビューで見逃してはならない。
except: passによるエラー無視- 処理と例外補足が混在して意図が読めない
- 例外の発生箇所が広範囲に及ぶ
- 捕捉される例外種が不明瞭・過剰
レビューでは単なる構文誤用だけでなく、「構造として例外処理が正しい位置に置かれているか」を判断する必要がある。
悪い例：例外処理が処理ロジックを覆い隠しているケース
ロジックが隠蔽された例
def process_data(data):
try:
value = int(data["value"])
result = compute(value)
log_result(result)
except:
passComment
@Reviewer: `except:`で全例外を無視しており、どの処理が失敗したかが不明です。最低限のログ出力と、例外ごとの補足を検討してください。このようなコードは、実行時の異常を完全に黙殺するため、障害が発生しても発見が困難になる。
構造的改善：tryスコープの粒度とexceptの明示化
スコープを明確にした例
def process_data(data):
try:
value = int(data["value"])
except (KeyError, ValueError) as e:
logger.warning(f"Invalid data: {e}")
return
result = compute(value)
log_result(result)改善点：
- 例外の発生可能箇所を最小限に限定
- 捕捉する例外タイプを明示
- ログ出力によって異常の検知が可能に
構造的に、通常処理と例外処理の境界が明確になり、責務が分離されている。
処理と例外の境界
このようにtryのスコープと構造的境界を意識することで、処理の意図とエラー発生箇所が明示化される。
よくあるレビュー指摘ポイントと判断基準
| 構造上の問題例 | 指摘観点 | 提案内容 |
|---|---|---|
except: pass |
エラー無視。ログも出ず、障害検知不可能 | 最低限のlogger.warning()を追加すべき |
| 広すぎるtryブロック | どの行でエラーが出たか判断できない | tryブロックを処理単位に絞る |
except Exception |
無差別捕捉。業務エラーとシステムエラーの混在 | 捕捉する例外クラスを限定する |
| 複数の処理を1つのexceptで処理 | 処理と失敗時の因果関係が曖昧 | ブロック分離・個別ログ出力を検討 |
| except内でprintだけして終了 | エラーが開発者にしか伝わらず運用視点がない | ログレベル設定と出力先の構造を見直す |
黙殺された例外処理の是正提案
例外処理に対するレビューやりとり
def save(user):
try:
db.insert(user)
audit_log(user)
except:
pass
@Reviewerすべての処理を無差別にtryで囲っており、ログも出力されていません。どの処理が失敗したのか判断できません。@Developer失敗しても致命的ではないので、無視してもよいかと…@Reviewer無視は問題を隠すだけです。最低限のエラーログと、どの操作に失敗したかが判る構造に分けるべきです。
リファクタ提案：tryの粒度と責務の明確化
明示的なログと分離構造による改善
def save(user):
try:
db.insert(user)
except DBError as e:
logger.error(f"Failed to insert user: {e}")
return
try:
audit_log(user)
except LogError as e:
logger.warning(f"Audit log failed: {e}")このように責務単位でtry-exceptを分けることで、障害の影響範囲が限定され、復旧や解析も容易になる。
まとめ：レビューアーが例外処理を設計視点で見るために
例外処理は「発生したときの対応」ではなく、「どこまでを許容し、何を記録し、どう責務を切り出すか」という設計そのものである。
レビューアーは次の観点で例外構造を評価すべきである：
- tryブロックの範囲が広すぎないか？
- 捕捉すべき例外が明示されているか？
- エラー時に記録・通知する仕組みが存在するか？
- 通常処理と例外処理が混在しすぎていないか？
例外処理は“保険”ではなく“設計の一部”である。
それをどう構造として位置付けているかを読むことが、レビューアーの役割である。