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

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

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

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

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

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

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

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

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

※アイキャッチ画像は、話題の生成AIで作成してみました。

public record UserType
{
   public static readonly UserType NormalUser = new(0);
  public static readonly UserType PremiumUser = new(1);

private UserType (byte value ) => Value = value;

public byte Value {get;}

public static UserType Parse(byte value) =>
value switch
{
0 => new UserType(value),
1 => new UserType(value)
_ => // throw Exception
};

例えばこんなValueObjectがあるとしたとき、これは定数として定義されていないので普通通りやるとswitch式の条件に使うことができない。

public string hogehoge()
{
  UserType t = repository.FindUserType();
  return t switch {
  UserType.NormalUser => "無料会員",
  UserType.PremiumUser => "プレミアム会員",
  _ => "会員ではない"
};

「ValueObjectなので、定数っぽく使ってswitchに載せたい」というのが書き手の意図なわけだけれども、C#の文法上これは許されていなくて、この書き方ではコンパイルエラーになってしまう。

そこで、最近のC#に導入されている型のパターンマッチングと組み合わせて、not null when～を使うとそれっぽく書くことができる。

return t switch
{
  not null when t == UserType.NormalUser => "無料会員",
  not null when t == UserType.PremiumUser => "プレミアム会員",
  _ => "会員ではない"
};

項目が増えるとnot nullの羅列になるので、ここのところはシンタックスシュガー的なアシストが欲しいなと思う今日このごろ。（あるいは、もっと良い書き方を知りたい）