「switch文のデバッグでフォールスルーを見つける方法」ですね。実務でよくハマるポイントなので、整理してコツをまとめます。
フォールスルーとは？
- breakを書き忘れると次のcaseまで処理が流れる現象。
- 意図的に使う場合もあるが、初心者や実務では「バグの原因」になりやすい。
デバッグのコツ
1. ログを仕込む
switch (status) {
case 1:
logger.debug("case 1 に入りました");
// 処理
break;
case 2:
logger.debug("case 2 に入りました");
// 処理
break;
default:
logger.debug("default に入りました");
}
- 各caseの先頭にログを入れると「どこに入ったか」が一目で分かる。
- breakが抜けていると「複数のログが連続で出る」のでフォールスルーを発見できる。
2. 意図的なフォールスルーにはコメントを残す
switch (num) {
case 1:
case 3:
case 5:
// ↓フォールスルーで奇数まとめ
System.out.println("奇数");
break;
case 2:
case 4:
System.out.println("偶数");
break;
}
- 「意図的にフォールスルーしている」場合は必ずコメントを書く。
- コメントがないのにフォールスルーしていたら「バグの可能性大」。
3. 静的解析ツールやIDEの警告を活用
- EclipseやIntelliJなどのIDEは「breakがない」caseに警告を出してくれる。
- SonarLintなどの静的解析ツールも「フォールスルーの可能性」を検出可能。
- 実務では「警告を無視しない」ことが大事。
4. テストケースを網羅する
- switchの入力値を全パターンテストする。
- 例えば曜日なら1〜7とそれ以外を必ずテスト。
- フォールスルーがあると「想定外の出力」が出るので気づける。
5. defaultで必ずログや例外を出す
default:
logger.error("未定義の値: {}", value);
throw new IllegalArgumentException("不正な入力値: " + value);
- defaultを「保険」として必ず書く。
- 想定外の値が来たときにログや例外を出すことで、バグを早期発見できる。
まとめ
- ログを入れる → フォールスルーが一目で分かる
- 意図的なフォールスルーにはコメント必須
- IDEや静的解析ツールの警告を活用
- テストで全パターンを確認
- defaultで異常検知
👉 実務では「break忘れ」は本当に多いバグです。
