意図的フォールスルーは「見た目は危険だけど、設計上便利に使える場面」があります。ここでは実務で使われる代表的パターン ➜ 何を期待しているか ➜ 実例コード ➜ 安全に使うための注意点、を順に示します。
使われる場面（高レベル）
- 特殊処理→共通処理の順に実行したいとき
あるケースだけ追加処理をした後で、共通の後処理も走らせたい場合。 - 逐次処理（ステップを順に実行）したいとき
「あるステップから最後のステップまで順に実行」するワークフローで便利。 - 累積的な処理
ある条件から上位（または下位）も含めて段階的に処理したいとき。 - 意図的にグルーピングせず、処理の流れを利用する場合
ただの複数ラベルのグルーピングならcase A: case B: ...が普通。フォールスルーは「順に処理を続ける」意図がある場合に使う。
実務例とコード
例1 — 特殊処理＋共通処理（ログ通知 → 共通ログ）
あるエラー CRITICAL のときは管理者通知も行い、その後で通常のログ処理も行いたい。
enum Severity { INFO, WARN, ERROR, CRITICAL }
switch (severity) {
case CRITICAL:
notifyAdmin("critical error happened"); // CRITICAL 特有の処理
// fall through
case ERROR:
logError(details); // CRITICAL と ERROR の両方で必要な処理
break;
case WARN:
logWarn(details);
break;
case INFO:
logInfo(details);
break;
}
ポイント：CRITICAL のときは notifyAdmin() → 続けて logError() を実行したいので break を置かずに流す。
例2 — ステップ実行（途中から残りを順に実行）
バッチ処理で、途中のステップから再実行するときにその番号から最後まで順番に処理したい。
int startStep = 2; // 1〜4 のステップ。2 から最後まで再実行したい場合
switch (startStep) {
case 1:
step1();
// fall through
case 2:
step2();
// fall through
case 3:
step3();
// fall through
case 4:
step4();
break;
default:
throw new IllegalArgumentException("invalid step");
}
こうすると startStep == 2 の場合 step2(), step3(), step4() が順に実行されます。リトライや途中再開に使えます。
例3 — 累積的処理（権限やレベルに応じた段階的付与）
「上位レベルは下位の権限も含む」ロジックを段階的に実行する例。
enum Role { GUEST, USER, MODERATOR, ADMIN }
switch (role) {
case ADMIN:
enableAdminFeatures();
// fall through
case MODERATOR:
enableModeratorFeatures();
// fall through
case USER:
enableUserFeatures();
// fall through
case GUEST:
enableGuestFeatures();
break;
}
ADMIN なら上から順に全部有効化されます（累積付与）。
なぜ stacked case（複数ラベル）だけではダメなのか？
- stacked
case（case A: case B: ...として１つの処理にまとめる）は**「どれかに一致したら同じ1つの処理だけを行う」**場合に使う。 - フォールスルーは 「最初の処理を行ったあと、さらに続けて別の処理も実行する」 意図があるときに使う（処理の順序が重要）。
安全に意図的フォールスルーを使うためのルール（実務ベストプラクティス）
- 必ず明示コメントを書く
// fall throughや// intentional fall-throughを書く。IDE の警告を抑える意味でも有効。 - 1つの
caseが長くなりすぎないようにする
小さなヘルパーメソッドに分けて可読性を保つ。 - ユニットテストを書く
各caseの振る舞い（順序・重複呼び出しの有無）を自動テストで検証。 - ログを残す（特に重要処理）
どのcaseを通ったかログに残しておくと、後で問題が起きたときに判別しやすい。 - コードレビューで意図を確認してもらう
フォールスルーは意図しないバグと紛らわしいため、レビューで必ず注目してもらう。 - 可能なら別の構造に置き換え検討
複雑になりすぎる場合はif/else、ポリモーフィズム、戦略パターン、コマンドパターンなどに置き換えたほうが安全なときがある。
小さなチェック例（コメントの書き方）
case X:
doX();
// fall through intentionally to handle common cleanup in case Y
case Y:
doCommonCleanup();
break;
IDE（IntelliJ/Eclipse）はこのコメントを見て「意図的」と扱ってくれることが多いです。
まとめ（いつ使うべき？）
- 「順番に処理を続けたい」という明確な意図があるときに使う。
- 単に複数ラベルをまとめたいだけなら
case A: case B:のほうが安全で読みやすい。 - フォールスルーを使う場合は コメント＋テスト＋レビュー を必須にして、曖昧さを排除する。