やあ。Dartの世界へようこそ。
Dart 3で導入された「パターンマッチング」と「switch式」。これらは単なる構文糖衣ではなく、コンパイラが型システムをどれだけ深く理解しているかを証明する強力な武器です。
今日は、多くの開発者が一度は直面する「網羅性チェック（Exhaustiveness Checking）の壁」について、あえて踏み込んで議論してみましょう。なぜDartはこれほどまでに「全てのケースを網羅しろ」と厳しく要求してくるのか。そして、それを「あえて」回避する設計にはどんなリスクと知恵が隠されているのか。
コードの深淵を覗く準備はいいですか？
—
1. そもそも「網羅性チェック」とは何か？
Dart 3のswitch式は、入力された値の全ての可能性をコンパイラが検証します。もし`enum`や`sealed class`のサブタイプが一つでも漏れていれば、コンパイルは通りません。
enum Status { ready, loading, error }
String getMessage(Status status) => switch (status) {
Status.ready => ‘準備完了’,
Status.loading => ‘読み込み中’,
// ここで Status.error が抜けていると、コンパイルエラーになる
};
これがなぜ重要かというと、「将来的な仕様変更をコンパイラが検知してくれるから」です。もし後から `Status.success` が追加されたら、コンパイラが「おい、ここを忘れているぞ」と教えてくれます。バグの温床を未然に潰す、Dartの守護神のような機能ですね。
—
2. 「あえて」回避したくなる状況とは？
しかし、現場では「どうしても全てのパターンを書きたくない」というシーンに出くわすことがあります。
- APIレスポンスの拡張性: サーバー側が新しいステータスを勝手に追加してくるが、アプリ側は特定のケース以外は「とりあえずデフォルト値」で動かしたい場合。
- 巨大な階層構造: 網羅するにはあまりに巨大すぎて、特定の枝葉だけを処理したい場合。
ここで多くの初心者がやりがちな「禁じ手」が、`default`句やワイルドカードの乱用です。
陥りやすい罠：ワイルドカード（_）の安易な利用
// これはコンパイルは通るが、本質的なリスクを隠蔽している
String getMessage(Status status) => switch (status) {
Status.ready => ‘準備完了’,
_ => ‘その他’, // 全てを飲み込んでしまう
};
一見便利に見えますが、これでは「新しいステータスが増えたこと」に気づけません。あなたのアプリケーションは、「型安全という名のコンパス」を捨てて航海に出ることになります。
—
3. どう回避し、どう設計すべきか？（アーキテクチャの知見）
もし「網羅性チェックを回避せざるを得ない」状況なら、それは「網羅性チェックが不要なほど抽象度を上げるべき」という設計上のサインかもしれません。
推奨される回避策：拡張機能と例外処理の分離
もし網羅を強制されたくないのなら、「未知のケース」を型として定義し、それを処理する責任を分離するのがプロの作法です。
// 未知の値を安全に扱うためのガード
String getMessage(Status status) {
return switch (status) {
Status.ready => ‘準備完了’,
Status.loading => ‘読み込み中’,
Status.error => ‘エラー発生’,
// 網羅性チェックをパスしつつ、将来の拡張にも耐える
};
}
もし、どうしても網羅したくないという強い動機があるなら、「あえて網羅性チェックを無効化する」のではなく「未知のパターンを明示的に扱う」設計に変えてください。
具体的には、以下のように「その他」を明示的に定義する手法を推奨します。
// 拡張性を持たせたパターンマッチング
String getMessage(Status status) {
final result = switch (status) {
Status.ready => ‘準備完了’,
Status.loading => ‘読み込み中’,
Status.error => ‘エラー’,
// 網羅性を満たした上で、あえて「未知」を許容する設計に
_ => throw UnimplementedError(‘未定義のステータス: $status’),
};
return result;
}
—
4. チーフアーキテクトからのアドバイス
Dartのコンパイラは、あなたを困らせるために存在しているわけではありません。「実行時に落ちるリスク」を「コンパイル時に直せる課題」に変換してくれているのです。
網羅性チェックを回避するということは、その「安全のバリア」を自分で取り払う行為です。もしあなたが現場で「`_`（ワイルドカード）で全部逃げよう」と考えているなら、一度立ち止まってこう自問自答してください。
> 「このスイッチ式に新しい型が増えたとき、私のコードはそれを知るべきか、無視すべきか？」
「知るべき」なら網羅すべきですし、「無視すべき」ならそもそもその型がその処理に依存している設計そのものを再考すべきです。
—
まとめ
1. 網羅性チェックは敵ではなく、あなたのコードの守護神です。
2. ワイルドカード（_）による回避は、設計の怠慢を隠す行為になりがちです。
3. どうしても網羅したくないなら、未知のケースを明示的に投げる（throw）設計にし、早期に異常を検知できるようにしましょう。
ここをマスターすれば、あなたの書くDartコードは驚くほど堅牢で、メンテナンス性の高いものに変わります。Dart VMも、そして何より未来のあなた自身が、そのコードに感謝することになるはずですよ。
さあ、次はどんな深いコードを書いてみましょうか？