【要約】finallyのreturnが、tryの失敗を握りつぶしていた話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がデータ取得処理において、エラーが成功と誤認される問題に直面した。調査の結果、以下の技術的課題が判明した。
- ・スクレイピング対象のURLパスが変更され、404エラーが発生していた。
- ・
except節でのエラー返却が、finally節のreturnにより上書きされていた。 - ・古いコメントを信じて調査を誤ったため、原因特定に時間を要した。
- ・エラー検知の仕組み自体が、静かに機能不全に陥っていた。
// Approach
調査チームは、コード内のコメントを疑い、Pythonの言語仕様に基づいた根本的な修正を実施した。具体的には以下の手順を踏んだ。
- ・実際のサイトへアクセスし、現状の構造を直接確認した。
- ・
finally節内に記述されていた、無条件なreturn文を削除した。 - ・正常系の
returnをtry/exceptブロックの後に配置し、制御フローを整理した。 - ・修正後、意図的にエラーを発生させ、失敗が正しく伝播するかを確認した。
// Result
修正により、エラー検知機能が正常に動作し、データの取得漏れを正しく報告できるようになった。得られた成果は以下の通りである。
- ・パスの修正により、取得件数が0件から7件へと改善した。
- ・
finallyによる戻り値の上書きが解消され、エラーが正しく伝播するようになった。 - ・修正前後のデータを比較し、期待通りの数値変化が得られることを実測した。
- ・異常なデータ取得を即座に検知できる、堅牢な仕組みが構築された。
Senior Engineer Insight
>
finally内でのreturnは、エラーハンドリングを破壊する極めて危険な実装である。これは「サイレントな失敗」を招き、システムの監視を無効化する。大規模なトラフィックを扱う現場では、エラーが検知できないこと自体が最大の運用リスクとなる。コードのコメントや「0件」という結果を盲信せず、言語仕様に基づき厳格に検証すべきである。小さな修正の裏に、より深いバグが隠れている可能性を常に考慮せよ。