Dartを掌握する極限の知見：Dart 3パターンマッチングとswitch式によるResult型エラーハンドリングの要塞化
ランタイムエンジンの設計に長く携わっていると、例外機構（`try-catch` と throw）がいかにプログラマの意図しない制御フローのバイパスを生み、イベントループの予測可能性をスポイルするか痛感させられる。例外は非局所的なジャンプ（Non-local jump）を引き起こし、Dart VMのスタックトレース生成コストやJIT/AOTにおける最適化の障壁となる。
本稿では、Dart 3で導入された網羅的な `switch` 式とパターンマッチングを駆使し、例外を完全に排除した `Result
—
1. 例外機構のコストと型システムによる強制力
従来の `try-catch` によるエラーハンドリングの最大の問題は、「型システムがエラー処理を強制しない」 点にある。関数シグネチャを見ただけでは、その関数がどのような例外を投げるのか（あるいは投げないのか）を静的に知ることはできない。結果として、プロダクションコードは防衛的になりすぎたり、逆に未処理の例外によってIsolate全体のクラッシュ（Uncaught Exception）を招いたりする。
Dart 3の代数的データ型（ADT）的なアプローチとパターンマッチングを使用することで、エラーハンドリングを「コンパイル時の強制規約」へと昇華させることができる。
—
2. 零コスト抽象化に近い `Result` の設計
まずは、メモリ効率とアロケーションを極限まで削ぎ落とした `Result` 型を定義する。ここでは、Dartのシールドクラス（`sealed class`）を活用し、コンパイラにサブタイプの網羅性を認識させる。
// sealed modifierにより、このファイル外でのサブクラス化をコンパイル時に禁止する。
// これにより、後続の switch 式で exhaustive（網羅的）チェックが強制される。
sealed class Result
const Result();
// 成功値へのアクセス（安全なアンラップ）
bool get isSuccess => this is Success
bool get isFailure => !isSuccess;
}
final class Success
final T value;
const Success(this.value);
}
final class Failure
final E error;
const Failure(this.error);
}
コンパイラの視点：なぜ `sealed` が重要なのか？
`sealed class` が指定された階層構造において、DartのCFA（Control Flow Analysis）および型推論エンジンは、すべての派生型を完全に把握する。
後述する `switch` 式において、すべてのケース（`Success` と `Failure`）が網羅されていない場合、コンパイルエラーとなる。これにより、「エラーハンドリングの書き忘れ」という人為的ミスを物理的に排除する。
—
3. `switch` 式によるパターンマッチングと網羅的検証
従来の手続き型 `switch` 文とは異なり、Dart 3の `switch` 式は値を返すため、関数型言語におけるパターンマッチングと同等の表現力を獲得している。
以下の実践的なデータフェッチおよびパース処理のパイプラインを見てほしい。
// ドメイン固有のエラー定義
sealed class DomainError const factory DomainError();
final class NetworkError extends DomainError {
final int statusCode;
const NetworkError(this.statusCode);
}
final class ParseError extends DomainError {
final String message;
const ParseError(this.message);
}
// 非同期処理をシミュレートする関数
Future
// 低レイヤのI/O例外をキャッチし、ドメインエラーとしてのResultに封じ込める
try {
// ネットワークコールの擬似コード
if (userId.isEmpty) {
return const Failure(NetworkError(400));
}
// 成功時
return Success({‘id’: userId, ‘name’: ‘Architect’});
} catch (e) {
return Failure(ParseError(e.toString()));
}
}
// 消費側（Consumer）の実装
Future
// fetchUserData の結果は必ず Result型であり、例外は上位に伝播しない
final result = await fetchUserData(userId);
// switch 式による網羅的パターンマッチング
final formattedOutput = switch (result) {
Success(value: final data) => ‘User authenticated: ${data[‘name’]}’,
Failure(error: NetworkError(statusCode: 400)) => ‘Bad Request: Invalid User ID’,
Failure(error: NetworkError(statusCode: final code)) => ‘Network Failure [HTTP $code]’,
Failure(error: ParseError(message: final msg)) => ‘Deserialization Error: $msg’,
};
print(formattedOutput);
}
—
4. Dart VM / AOT コンパイラにおける実行時挙動の最適化
ここでシニアエンジニアとして深掘りすべきは、この構造がランタイムにどのような負荷を与えるかという点である。
1. アロケーションの最小化 (`const` コンストラクタ):
`Success` や `Failure` は、可能な限り `const` としてインスタンス化されるべきである。Dart VMヒープ上でのオブジェクト生成コストをゼロ（定数プールからの参照）に近づけることで、GC（ガベージコレクション）のプレッシャーを劇的に軽減できる。
2. インラインキャッシュとディスパッチ:
`switch` 式の評価において、Dart VMは型テスト（Type Test）とオブジェクトのタグチェックを行う。`sealed` クラスのサブタイプが閉じた世界（Closed world）にあるため、AOTコンパイラ（Dart Native）はクラス階層解析（Class Hierarchy Analysis: CHA）を行い、冗長なディスパッチを直接ジャンプ（Devirtualization）に最適化できるケースが多い。
3. イベントループへの影響:
例外オブジェクトの生成には、スタックトレースのキャプチャ（VM内部でのネイティブスタックフレームの走査）という極めて重い処理が伴う。`Result` 型によるエラー伝播は、通常のオブジェクト参照の受け渡しに過ぎないため、イベントループのマイクロタスクキュー（Microtask Queue）やイベントキュー（Event Queue）の遅延（Jank）を発生させない。リアルタイム性の求められるFlutterのレンダリングパイプラインや高スループットなサーバーサイドDartにおいて、これは決定的なアドバンテージとなる。
—
5. 高度なコンビネータの導入：パイプライン処理の要塞化
実戦では、複数の `Result` を返す処理を連続して実行（チェーン）したくなる。ここでもパターンマッチングの応用が生きる。`map` や `flatMap` に相当する拡張メソッドを定義することで、モナディックな処理系を構築できる。
extension ResultExtensions
Result
return switch (this) {
Success(value: final v) => Success(transform(v)),
Failure(error: final e) => Failure(e),
};
}
Result
return switch (this) {
Success(value: final v) => transform(v),
Failure(error: final e) => Failure(e),
};
}
}
この拡張により、エラーハンドリングのボイラープレートを排除しつつ、制御フローの安全性を100%保つことが可能になる。
void main() async {
// パイプラインの構築例
final result = await fetchUserData(‘007’)
.then((res) => res.map((data) => data[‘name’] as String))
.then((res) => res.map((name) => name.toUpperCase()));
switch (res) {
case Success(value: final name):
print(‘Processed Name: $name’);
case Failure(error: final err):
print(‘Pipeline halted due to: $err’);
}
}
—
結言
例外処理の排除と `Result` 型による型安全なエラーハンドリングは、単なる「お作法」や「デザインパターン」ではない。それは、コンパイラの静的解析能力を最大限に引き出し、ランタイムの予測不可能な挙動（例外によるクラッシュや重いスタックトレース生成）をエンジニアの制御下に置くための防壁である。
Dart 3の `sealed class` と `switch` 式という強力な武器を手に入れた我々は、もはやランタイムの気まぐれに怯える必要はない。堅牢で、予測可能で、かつ極限まで最適化されたコードベースを、その手で構築し続けよ。