1. 導入：なぜswitch文でのNullは危険なのか
Javaの実務において、NullPointerException (NPE) は最も頻繁に遭遇するバグの一つです。特に従来型のswitch文（Java 16以前の挙動を引きずるケース）では、switchの対象変数にnullを渡すと、caseラベルの判定以前に即座にNPEが発生します。これはコードの堅牢性を損なう大きな要因です。本記事では、この課題を解決し、より安全で読みやすいコードを書くためのモダンな制御フローの活用法を解説します。
2. 基礎知識：Null-hostile（Nullに敵対的）な仕組み
従来型のswitch文は、内部で対象変数のハッシュ値やequalsメソッドを呼び出す仕組みになっています。そのため、対象変数がnullの場合、これらのメソッドを呼び出した瞬間にJVMが例外をスローします。
一方、Java 17以降で導入された「パターンマッチング」や「switch式」では、nullに対する挙動がより明示的かつ柔軟になっています。これらを活用することで、従来のif-elseのネスト地獄を回避しつつ、安全なコード記述が可能になります。
3. 実装/解決策：モダンな構文への移行
NPEを避けるための最善策は、「nullチェックを隠蔽する」のではなく、「制御フローの中にnullを明示的に組み込む」ことです。
Java 17以降のswitch式では、以下のようなアプローチが推奨されます。
・nullガードをswitch内に含める（case null）。
・Sealed Classes（封印クラス）を使用して、型の網羅性を強制し、nullや未知の型による予期せぬ挙動を防ぐ。
4. サンプルプログラム：安全な制御フローの実装
以下に、nullを安全に扱い、かつ可読性を高めた実装例を示します。
public class SwitchSafetyDemo {
// 封印クラスを用いて型の網羅性を担保（Sealed Classes）
public sealed interface Status permits Active, Inactive {}
public record Active() implements Status {}
public record Inactive() implements Status {}
public String processStatus(Status status) {
// switch式を使用し、nullを明示的にハンドリング
return switch (status) {
// nullが渡されてもNPEにならず、ここで処理可能
case null -> “状態が指定されていません”;
case Active a -> “アクティブなユーザーです”;
case Inactive i -> “非アクティブなユーザーです”;
// defaultは不要（sealedにより全ケースが網羅されているため）
};
}
public static void main(String[] args) {
SwitchSafetyDemo demo = new SwitchSafetyDemo();
// nullを渡しても安全に動作する
System.out.println(demo.processStatus(null));
System.out.println(demo.processStatus(new Active()));
}
}
5. 応用・注意点：現場で陥りやすい罠
現場でモダンな制御フローを導入する際、以下の点に注意してください。
・レガシー環境の罠：古いライブラリと連携する場合、戻り値がnullになるケースが多々あります。switch式を採用する際は、必ず case null を記述する習慣をチームで共有してください。
・網羅性の重要性：Sealed Classesを使わない場合、switch式では default ラベルが必須となります。将来的な要件変更（新しい型の追加）でdefaultにフォールバックされると、バグの発見が遅れる可能性があります。可能な限り、型を封印してコンパイル時に網羅性をチェックさせる設計を心がけましょう。
・if-elseとの使い分け：単なるnullチェックであれば Optional を使用し、状態による分岐であれば switch式 を使うという使い分けが、モダンJavaのベストプラクティスです。
コメント