1. 導入：例外を追うだけで一日が終わる絶望
「どこでエラーが起きたのか分からない……」 以前、他人が書いたコードの保守をしていた際、例外処理の迷宮に迷い込み、原因を特定するためだけに数時間を費やすという苦い経験をしました。
例外が何層ものクラスを無意味に突き抜け、戻り値の数値でエラーを判定していたそのコードは、まさに「解読不能なパズル」でした。そんな実体験から導き出した、保守性を劇的に高めるための2つのマイルールを共有します。
2. ルール①：戻り値で例外を判断しない
エラーが起きた時に「戻り値として -1 や null を返す」手法は、一見手軽ですが、実はバグの温床です。
実体験の罠： あるメソッドがエラーで
-1を返し、それを受け取った別のメソッドがさらに別の計算にその-1を使ってしまい、最終的に「全く関係ない場所」でシステムが落ちる……。こうなると、真犯人（原因箇所）を探すのは至難の業です。解決策： 異常事態には、潔く「例外（Exception）」を投げます。戻り値にエラーの意味を持たせず、「正常系」と「異常系」を型のレベルで明確に切り離すのがプロの作法です。
3. ルール②：例外処理の責務を明確にする（連鎖を短く）
どこまでも throws で例外を上位に投げ飛ばす「例外のバケツリレー」は、コードを劇的に読みにくくします。
私のマイルール：
発生場所の責任： 例外が発生したクラス内で、可能な限り原因の特定とログ出力を完結させる。
呼び出し側の責任： 呼び出した側は、そのエラーを受けて「処理を止めるのか、別の道（リカバリ）を探すのか」というフロー制御だけに専念する。
例外の連鎖を短く保つことで、スタックトレース（エラーの履歴）が簡潔になり、トラブル時の調査スピードが格段に上がります。
4. なぜこのルールが「納得感」に繋がるのか
ルールが決まっていないコードがもたらす最大の害悪は、開発者の「迷い」を生むことです。
「どこで落ちたか分からない」： 例外が何層も転送されるうちに、元の例外情報が書き換えられたり、消えたりしてしまう。
「二重、三重のログ出力」： 各階層で「念のため」とログを出すため、ログファイルが同じエラーメッセージで埋め尽くされ、本当に必要な情報が埋もれる。
実際に迷宮にハマった私だからこそ断言できます。例外処理はエラーを隠すためのものではなく、**「次に何が起きるべきかを、誰が見ても分かるように示すもの」**であるべきです。
5. まとめ：保守性の高いコードは「誠実」である
今回の探求で、例外処理は単なる「エラー対策」ではなく、**「クラス間の責任の押し付け合いを防ぐための契約」**なのだと確信しました。
「とりあえず投げる」「適当な値を返す」といったその場しのぎの処理は、必ず未来の自分や仲間に跳ね返ってきます。ルールをシンプルに保つことで、迷いのない、寿命の長いシステムを築いていきたいと思います。
0 件のコメント:
コメントを投稿