型システムで「不可能性」を証明せよ：Dartの『Never』型による極限のNull安全制御
フロントエンドの実装において、我々が最も忌むべきは「不確実性」だ。
「ここにはデータが来るはずだ」「このエラーは起こり得ないはずだ」――こうした希望的観測が、ランタイムでのNull Pointer Exceptionや、予期せぬ状態遷移を引き起こす。
DartのSound Null Safetyは強力だが、多くのエンジニアはその真価を使いこなせていない。特に、ボトム型（Bottom Type）である『Never』型の活用こそが、コンパイラを味方につけ、デッドコードを排除し、コードの堅牢性を次元の違うレベルへと引き上げる鍵となる。
今日は、なぜ君たちの書くエラーハンドリングが「甘い」のか、そして `Never` を使ってどう「完璧」に近づけるのかを、Dart VMの挙動と型システムの観点から徹底的に解説する。
—
1. 『Never』型とは何か：型システムの底辺を知る
Dartの型階層において、すべての型の頂点にあるのが `Object?` ならば、その対極、最底辺に位置するのが `Never` だ。
`Never` 型は「値を持つことができない」ことを意味する。もし関数の戻り値が `Never` ならば、その関数は「呼び出し元に制御を戻すことが絶対にない」ことをコンパイラに対して宣言していることになる。
なぜ `void` では不十分なのか？
`void` は「戻り値に意味がない」ことを示すだけで、関数自体は正常に終了し、次の行へと実行が移る。
一方で `Never` は、関数内で必ず `throw` するか、`exit()` するか、あるいは無限ループに陥ることを保証する。
これがコンパイラの制御フロー解析（Control Flow Analysis）に劇的な影響を与える。
—
2. 実践：`Never` による到達不能コードの明示と型昇格
例えば、APIレスポンスのバリデーションを考えてみよう。多くのエンジニアは以下のような、詰めの甘いコードを書く。
// 凡庸な実装：コンパイラは「ここが絶対安全であること」を理解できない
void processUser(User? user) {
if (user == null) {
handleError(‘User is required’);
// ここで return し忘れると、下の user.name でクラッシュする
}
print(user.name); // コンパイルエラー：userはnullの可能性がある
}
void handleError(String message) {
throw Exception(message);
}
このコードでは、`handleError` が例外を投げることをコンパイラは知らない。そのため、`user` が非Nullであることを確信できず、キャストや `!`（Bang operator）を強いてしまう。
これを `Never` を使って「プロフェッショナル」なコードに書き換える。
プロフェッショナルのコード：`Never` を用いた「パニック」関数
/// アプリケーション全体で一貫したエラーハンドリングを行うユーティリティ
/// 戻り値を [Never] にすることで、呼び出し側の制御フローを遮断する
Never panic(String message) {
// ログ出力、Sentryへの送信、デバッグ情報の収集などをここで行う
throw StateError(‘[FATAL]: $message’);
}
void processUser(User? user) {
// userがnullの場合、panic()が呼び出され、このスコープは「絶対に」終了する
// コンパイラはこの事実を型システムレベルで理解する
if (user == null) panic(‘User object is missing in critical path’);
// ここで user は自動的に User 型に「型昇格（Type Promotion）」される
// `!` も `as User` も不要だ。これが Dart の Sound Null Safety の真髄である
print(user.name);
}
—
3. 応用：Result型とNeverを組み合わせた網羅的エラーハンドリング
実務では、単に `throw` するだけでなく、エラーを値として扱いたい場面が多い。しかし、`Either` や `Result` 型を使っても、エラーケースの処理を強制できなければ意味がない。
Dart 3 で導入された Sealed Class と `Never` を組み合わせることで、コンパイル時に漏れのないエラーハンドリングを強制するパターンを構築できる。
実務でそのまま使える「堅牢なResultパターン」
import ‘package:meta/meta.dart’;
@sealed
sealed class Result
class Success
final T value;
Success(this.value);
}
class Failure
final Object error;
final StackTrace stackTrace;
Failure(this.error, this.stackTrace);
}
/// 決して値を返さない、エラー専用のResult
/// 共通の「回復不能なエラー」処理に利用する
class Fatal
final String message;
Fatal(this.message);
// この関数自体が Never を返すことで、呼び出し側に「死」を告げる
Never execute() => panic(message);
}
void main() {
final Result
// switch文による網羅性チェック（exhaustive check）
// Fatalケースで execute() を呼ぶことで、その後の処理が不要であることを示す
final data = switch (result) {
Success(value: final v) => v,
Failure(error: final e) => ‘Fallback: $e’,
Fatal f => f.execute(), // ここで Never が返るため、switch全体が成立する
};
print(‘Result: $data’);
}
Result
// 擬似的なロジック
return Fatal(‘Database connection leaked!’);
}
Never panic(String message) => throw Exception(v);
—
4. アーキテクトの視点：パフォーマンスと最適化
なぜ `Never` を使うことが、単なる「書きやすさ」以上の価値を持つのか。それは Dart VM (AOTコンパイラ) に対するヒントになるからだ。
1. デッドコードの削除 (Dead Code Elimination):
AOTコンパイラは、`Never` を返す関数の呼び出し以降のコードが絶対に実行されないことを確信する。これにより、バイナリサイズを削減し、不要な命令セットを排除できる。
2. レジスタ割り当ての最適化:
制御フローが合流しない（分岐が戻ってこない）ことが分かれば、コンパイラはレジスタの生存期間をより正確に管理でき、実行時のオーバーヘッドを極限まで削ぎ落とすことができる。
—
結論：君たちのコードに「終止符」を打て
`null` を許容する設計は、常に「不完全さ」を孕んでいる。しかし、`Never` 型を適切に配置することで、その不完全なパスを型システムの中で封じ込めることができる。
- 例外を投げる共通関数には必ず `Never` を付与せよ。
- 不可能な状態（Defaultケースなど）には `Never` を返す関数を配置し、コンパイラに安全を証明せよ。
- `!`（Bang operator）を使いたくなったら、それは設計の敗北だ。`Never` を使って型昇格を導け。
Dartの型システムは、単なる注釈ではない。それはランタイムの正しさを保証するための「数学的証明」だ。`Never` を使いこなし、コンパイラを最強のコードレビュアーに変えること。それが、真のチーフアーキテクトへの第一歩である。
君の次のプルリクエストから、無意味な `null` チェックが消えることを期待している。