Nullという名の「未定義の特異点」を制御する：Result型による設計の純化
DartのSound Null Safetyは、単なる「NullPointerExceptionを防ぐためのガードレール」ではない。これは、コンパイラが型システムを基盤として、メモリ上のビットパターンが「意味を持つか否か」を静的に証明するための数学的な防壁だ。
しかし、現場で遭遇する `if (x != null)` の連鎖（Nullチェック地獄）は、コードの可読性を損なうだけでなく、条件分岐という「予測不可能な副作用」をビジネスロジックに混入させる。
本稿では、Dartにおける `Result
—
1. 例外（Exception）という「非局所的ジャンプ」の脆弱性
Dart VMにおいて `throw` が実行されるとき、ランタイムは何を行っているか？
スタックトレースを生成し、現在の実行フレームを巻き戻し、呼び出し元の `catch` ブロックを探索する。この「非局所的ジャンプ」は、関数が本来果たすべき「入力に対する決定論的な出力」という契約を破壊する。
セキュリティ研究の視点から言えば、例外は制御フローの予測を困難にする「暗黙の分岐」である。APIの境界で例外を投げれば、呼び出し側はそれを捕捉し忘れるリスクを常に抱えることになる。
2. Result型による「計算状態の封じ込め」
Null許容型 `T?` は、情報の欠落を表現するが、その「理由」を保持できない。Result型は、成功（Success）か失敗（Failure）かという「計算の結果」を型として定義する。
/// 計算結果を包含する不変なコンテナ
/// コンパイラはこれをsealed classとして評価し、パターンマッチングを強制する
sealed class Result
const Result._();
// 成功時のコンストラクタ
factory Result.success(T value) = Success
// 失敗時のコンストラクタ
factory Result.failure(E error) = Failure
}
class Success
final T value;
const Success(this.value) : super._();
}
class Failure
final E error;
const Failure(this.error) : super._();
}
なぜこれが強力なのか
Dart 3.0以降の `sealed class` とパターンマッチングを組み合わせることで、コンパイラは「全ケースの網羅性」を静的に保証する。 もし `Failure` の処理を忘れていれば、コンパイラは即座にエラーを吐く。これはランタイムの安全性をコードの記述段階で強制することを意味する。
—
3. 実践：イベントループを汚さない関数型パイプライン
非同期処理におけるResult型の真価は、`Future` チェーンの中で発揮される。例外を投げずに値を運ぶことで、イベントループのキュー消費を予測可能な状態に保つことができる。
Future
try {
final response = await _api.fetchUser(token);
// 成功をResultで包む
return Result.success(User.fromJson(response));
} on NetworkException catch (e) {
// 失敗を値として型システムに渡す
return Result.failure(AuthError.network(e));
}
}
// 呼び出し側のハンドリング
void main() async {
final result = await authenticate(‘secret_token’);
// パターンマッチングで全てのケースを強制的に処理させる
switch (result) {
case Success(value: final user):
print(‘Welcome, ${user.name}’);
case Failure(error: final e):
print(‘Access Denied: ${e.message}’);
}
}
—
4. コンパイラ最適化とメモリ効率の深層
ここで、Dart VMアーキテクトとしての視点を提供する。
`Result` のようなラッパーオブジェクトを多用すると、ヒープ割り当てが増えるのではないか？という懸念があるかもしれない。
しかし、DartのAOT（Ahead-of-Time）コンパイラは、これらの短い生存期間を持つオブジェクトを「エスケープ解析（Escape Analysis）」によってレジスタに保持したり、スタック上に展開しようと試みる。特に `sealed class` による型階層は、JIT/AOTコンパイラにとってディスパッチの最適化（vtableの削減）が非常に効きやすい構造だ。
Null許容型 `T?` と比較して、`Result` は若干のオーバーヘッドがある。しかし、その代償として「予期せぬNull参照によるセグメンテーションフォールト」や「例外によるクラッシュ」という、システム全体を停止させるコストを排除できる。
結びに：Dartを使いこなすということ
DartにおいてNull安全とは、単なる型チェックではない。それは、「メモリ上の未定義な領域を、型システムという論理で完全に包囲し、制圧すること」である。
Result型を用いた設計は、コードの冗長さを一時的に増やすかもしれない。しかし、複雑なシステムにおいて「例外」という制御不能なブラックボックスを排し、すべてのエラーを値として扱うことは、堅牢なスケーラブル・アプリケーションを構築するための唯一の正解である。
コンパイラの警告を単なる警告と捉えるな。それは、君のコードに潜むバグに対する「未来からの警告」だ。その警告を型システムで封じ込めることこそ、一流のアーキテクトの矜持である。