Dartの『Never』型を極める：制御フローの終端を支配し、バグを「コンパイル時」に消滅させる
Dartの型システムにおいて、`Never`型は単なる「何も返さない」という記号ではない。これは、「このコードパスは決して到達せず、実行フローがここで永久に停止する（あるいは異常終了する）」という、コンパイラに対する極めて強力なアサーションだ。
多くのエンジニアは`void`と混同するが、`void`は「戻り値に興味がない」ことを示すに過ぎない。対して`Never`は、「これ以降のコードは、いかなる状態であっても実行されない」ことを型システムに保証させるための鍵だ。
今日は、Sound Null Safetyを最大限に活用し、実行時の例外をコンパイル時の警告へ押し込めるための『Never』の極意を伝授する。
—
1. なぜ「到達不能」を明示するのか？
実務でよくあるのが、`switch`文や`if-else`の網羅性チェックの欠落だ。TypeScript等の経験があるエンジニアほど、`default`句で適当な値を返して誤魔化しがちだが、それはDartでは技術的負債となる。
`Never`を使えば、フローの終端をコンパイラに教え込むことができる。
アンチパターン：値の握り潰し
// 良くない例：全てのパスで値を返す必要があるため、ダミー値を返す
String getStatusLabel(Status status) {
switch (status) {
case Status.active: return ‘有効’;
case Status.inactive: return ‘無効’;
// 実際にはありえないが、コンパイラを通すために適当な値を返す
default: return ‘unknown’;
}
}
改善案：Neverによる完全網羅
// 改善例：Neverを返す関数を定義し、コンパイラに「ここには来ない」ことを保証させる
Never unreachable(String message) => throw StateError(message);
String getStatusLabel(Status status) {
return switch (status) {
Status.active => ‘有効’,
Status.inactive => ‘無効’,
// 型推論により、もしStatusに新しい値が増えたらコンパイルエラーになる
_ => unreachable(‘予期せぬステータス: $status’),
};
}
このように設計すれば、将来的に列挙型が増えた際、`switch`文が即座にコンパイルエラーを吐く。これにより、「修正漏れ」というヒューマンエラーを物理的に排除できる。
—
2. 実務で光る：型安全な例外スローとNull安全
API連携や複雑なコンポーネント設計において、`null`の可能性があるオブジェクトから値を取り出す際、`!`（強制アンラップ）を多用するのは悪手だ。コードのあちこちに爆弾を仕掛けるようなものだ。
ここで「値がなければ例外を投げる」という処理を共通化することで、コードの可読性と安全性を高める。
/// 値が存在しない場合に例外を投げるためのユーティリティ
/// T? を受け取り、T を返すか、Never（例外）で処理を中断させる
T requireNotNull
if (value == null) {
throw StateError(message);
}
return value;
}
// 活用例：APIレスポンスのパース
void processUser(Map
// 名前がなければ即座に処理を中断し、以降のコードで name は確実に String となる
final name = requireNotNull(json[‘name’] as String?, ‘User name is required’);
print(‘Processing: ${name.length} characters’); // ここで name は確実に非Null
}
この`requireNotNull`の戻り値の型は`T`だ。しかし、もし`value`が`null`なら、関数は`Never`を返す。Dartコンパイラは、`throw`が実行された後のコードパスは「到達不能」であると理解するため、呼び出し元では`null`チェックのガード句を記述する必要がなくなる。
—
3. パフォーマンスとVMの挙動：なぜこれが「美しい」のか
「関数呼び出しのオーバーヘッドはないのか？」と問うアーキテクト気質のエンジニアへ回答する。
Dart VM（特にAOTコンパイラ）は、`Never`を返す関数に対して非常にアグレッシブな最適化を行う。到達不能パスが明らかであれば、そのパスをコード生成から除去する（Dead Code Elimination）ことも可能だ。また、`Never`は型システム上、他のあらゆる型のサブタイプであるため、ジェネリクスとの相性も抜群である。
「実行時のチェックを最小限にし、コンパイル時のチェックを最大化する」ことこそが、Dartのパフォーマンスを最大化する設計の極意だ。
—
4. 現場で使える：堅牢な設計パターンまとめ
プロダクションコードを美しく保つために、以下の3点を意識してほしい。
1. exhaustive switchを強制する: 網羅していない`switch`のデフォルト句には、必ず`Never`を返す関数を置く。
2. 強制アンラップ（`!`）を禁止する: `!`演算子は「思考停止」の証だ。代わりに`Never`を返す例外スロー・ユーティリティを定義し、意味のあるエラーメッセージを残せ。
3. フローの終端を明確にする: メソッドが「正常に終了しない」場合、必ず戻り値の型を`Never`に明示する。これにより、呼び出し側は型システムによって「その後の処理は書かなくて良い」という恩恵を受けられる。
コピペで使える最強のユーティリティ
/// プロダクションコードの網羅性チェック用
Never todo() => throw UnimplementedError(‘実装が必要です’);
/// nullを許容しないアクセス用
T ensure
value ?? (throw StateError(msg ?? ‘Value is unexpectedly null’));
Dartは、型システムがプログラマの意図をどこまで正確に汲み取れるかで、その品質が決定する。`Never`型は、君たちの書くコードが「意図した通りにしか動かない」ことを保証する、最も強力な防壁となるはずだ。
次は、Isolate間のメモリ共有と、この`Never`を組み合わせた「非同期ストリームの安全な中断」について深く掘り下げようと思う。今日のところは、まず君たちのコードから`!`を消し去ることから始めてほしい。