Robert C. Martin先生のCleanCode第7章を読んだメモ。

エラー処理(第7章)の概要

  • リターンコードではなく例外を使用する。
    • 処理の関心ごとと、エラー処理が分かれるから良いよ。
    • リターンコードは、呼び出し側が雑然としてしまい、忘れやすいよ。
  • 最初にtry-catch-finallyを書く
    • 例外をthrowする可能性のあるコードを書くときにtry-catch-finalyから書くのは良い習慣。
    • TDDを使って必要なロジックを実装することが可能になる。
    • tryブロックによるトランザクションスコープを作成できる。
  • 非チェック例外を使用する
    • チェック例外は利点もあるが、ソフトウェア開発に必ずしも必要なものではない。
      • C#やC++,Python,Rubyにもない。
    • チェック例外は代償としてOCPを失っている。
      • キャッチとの間にあるメソッドのシグネチャすべてに例外を追加せねばならず、下層の変更がより高いレベルのシグネチャ変更を強制することになる。
    • 例外送出の連鎖に含まれるすべての関数が下層における例外の詳細を知る必要があるのはカプセル化が壊れている。
    • しかし、重要なライブラリを書く際などは有効。
  • 例外で状況を伝える
    • 十分な情報を持ったエラーメッセージを作成し、それを例外に含める。
    • スタックトレースなど、catchした場所でロギングを行うのに十分な情報を渡す。
  • 呼び出し元が必要とする例外クラスを定義する。
    • いっぱいキャッチする必要があるなら、呼び出しているAPIをラップして共通の例外クラスを定義するようにする。
    • アプリケーションを特定のベンダのAPIの設計に依存させなくてすむ。
    • 特定の領域のコードでは、1つの例外クラスを使用することが適している。
  • 正常ケースのフローを定義する
    • 例外による処理の中断を望まないケース(外部API的には例外だが、アプリケーションとしては例外として扱いたくない)
    • スペシャルケースパターンを利用する。(返り値を本来のreturnと整合性のとれたオブジェクトにする)
  • nullを返さない
    • ほぼ1行おきにnullチェックをしているコードは数多くあるが、これらは問題のあるコード。
    • nullチェックを忘れれば制御不能となる。
    • スペシャルケースパターンを使え。
  • nullを渡さない
    • nullをメソッドに渡すのはnullを返さないよりよくない。
    • 多くのプログラミング言語では呼び出し元からnullを渡された場合にうまく対処する方法がない。
    • 理にかなった方法が、nullを渡すことを原則禁止にする。

感じたこと

基本例外throw派なので、すごく同意。
チェック例外は結構好きな部類だったが、確かに上記の問題を含んでいるなと思った。
なんとなく使っていたコードにスペシャルケースパターンという名前が付いていたことには驚いた。