C#: try-catchの認知負荷

try-catchのイメージ

人の書いたC#のコードを読んでいて、こんなコードに出くわした。

try {
     処理;
} catch(例外)
    例外処理;
}

try {
    別の処理;
} catch(別の例外)
    例外処理;
} catch(ほかの例外)
    例外処理;
}

間にtry-catchの処理にtry-catchが続けて書かれていて、書き方的な側面から見ると、これは下記のようなひとつのtry-catch文にまとめることができるハズだ。

try {
    処理;
    別の処理;
} catch(例外) {
    例外処理;
} catch(別の例外) {
    例外処理;
} catch(ほかの例外) {
    例外処理;
}

例外処理はフットプリントが大きいから極力使わないとか、そういう話は置いておいて、果たして書き方としてどちらの方が良いのだろうか?という気持ちになった。

処理⇒例外が近くに記述されている方が、コードを読む上での認知負荷は小さくなるように思うし、ひとつのTRY構文の中に複数の例外パターンが潜んでいる状態の方がコードを読む上での負担は大きいように感じる。

一方で、try-catch文を何度も書かずにまとめたほうがコードの見た目的にスッキリと見えるような気もしていて、スッキリしたように見えるならば、それはそれで認知負荷が小さい事の証左であるようにも思う。

結局、一カ所にまとめる方向でリファクタリングを進めるようにしているのだが、果たしてこの判断が正しいのか?と思ったのでメモに残しておく。