TypeScript非同期境界の要塞：Promise戻り値における型安全なエラーハンドリングの極限設計
TypeScriptの型システムは、その静的な表面積の広さに反して、実行時の非同期境界（Asynchronous Boundary）において容易にその牙を隠す。特に `async/await` や `Promise
シニアエンジニアやアーキテクトが直面する真の課題は、単に「エラーをキャッチできるか」ではない。「コンパイルタイムの型システムが、実行時における予期せぬ例外の伝播を完全に封じ込めているか」という点にある。
本稿では、TypeScriptコンパイラの型評価メカニズム、V8エンジンにおけるPromiseのジョブキュー消費モデル、そして型安全な例外処理を強制するための極限の設計パターンを解剖する。
—
1. 伝統的 `try/catch` が孕む構造的欠陥と型システムの盲点
TypeScriptにおいて、以下のようなコードは日常茶飯事に見られる。
async function fetchPayload(endpoint: string): Promise
const res = await fetch(endpoint);
if (!res.ok) throw new HttpError(res.status);
return res.json();
}
この関数を呼び出す側では、通常このように書くだろう。
try {
const user = await fetchPayload(‘/api/user’);
} catch (error) {
// error の型は `unknown` (noImplicitUseOnError 有効時) または `any`
console.error(error.message); // 🔴 危険：error が Error インスタンスとは限らない
}
ここに、TypeScriptの静的解析における最大の欺瞞がある。`catch (error)` 節における `error` は、ランタイムにおいて `string` かもしれないし、`null` かもしれない、あるいはプリミティブ値かもしれない。しかし、開発者は暗黙的に「 `Error` オブジェクトである」という非現実的な仮定のもとでコードを書く。
結果として、型安全性の保証範囲は `try` ブロックの内部のハネムーン期間で途切れ、`catch` 節に突入した瞬間にTypeScriptは無力なガードマンへと成り下がる。
—
2. 実行時イベントループとPromiseの型評価メカニズム
この問題を根本から解決するためには、V8エンジンがメモリ上で `Promise` をどう扱い、TypeScriptコンパイラ（`tsc`）がそれをどう型推論しているかを同期させる必要がある。
マイクロタスクキューと型推論の乖離
`async` 関数は、内部的に `Promise
TypeScriptの型チェッカーは、戻り値の型 `Promise
// 標準の Promise 定義の限界
interface Promise
then
// 失敗時の型 TResult2 は常に unknown や any に逃げやすい構造になっている
}
この仕様の隙間を突き、コンパイルタイムでエラーの型を強制的にキャプチャし、呼び出し元に「成功値かエラー値か」の二者択一（Discriminated Union）を強制するデザインパターンを構築しなければならない。
—
3. 実装：Result型による非同期エラーの完全封じ込め
Rust言語の `Result
以下のコードは、戻り値の型自体にエラーの可能性を内包させ、`try/catch` の記述すらコンパイラによって強制・管理させる究極のアーキテクチャである。
/
- 成功と失敗を厳密に表現する代数的データ型 (ADT)
/
export type Result
| { readonly ok: true; readonly value: T }
| { readonly ok: false; readonly error: E };
/
- 非同期関数の実行をラップし、例外を値（Value）へと昇華させる高階関数
- ランタイムの予期せぬスローを完全に型の世界に閉じ込める。
/
export async function safeAsync
fn: () => Promise
isExpectedError: (err: unknown) => err is E = (err): err is E => err instanceof Error
): Promise
try {
const value = await fn();
return { ok: true, value };
} catch (err: unknown) {
if (isExpectedError(err)) {
return { ok: false, error: err };
}
// 想定外の例外はそのまま再スローし、プロセス境界でのクラッシュを維持する（Fail-Fast原则）
throw err;
}
}
応用：ドメイン駆動における型安全なAPIクライアント
上記の `safeAsync` を用いて、実際の業務アプリケーションでどのように「型安全な例外処理の強制」が機能するかを示す。
// ドメイン固有のエラー定義
class NetworkError extends Error {
readonly _tag = ‘NetworkError’;
constructor(public statusCode: number, message: string) {
super(message);
}
}
class ParseError extends Error {
readonly _tag = ‘ParseError’;
}
type ApiErrors = NetworkError | ParseError;
interface UserProfile {
id: string;
name: string;
}
// —————————————————————–
// 戻り値の型でエラーを完全制御する関数定義
// —————————————————————–
async function fetchUserProfile(userId: string): Promise
return safeAsync(
async () => {
const response = await fetch(`https://api.internal/users/${userId}`);
if (!response.ok) {
throw new NetworkError(response.status, `Failed to fetch user: ${response.statusText}`);
}
try {
return (await response.json()) as UserProfile;
} catch {
throw new ParseError(‘Failed to parse JSON payload’);
}
},
// 型ガードにより、想定外のエラー（TypeErrorなど）とドメインエラーを厳密に分離
(err): err is ApiErrors => err instanceof NetworkError || err instanceof ParseError
);
}
// —————————————————————–
// 呼び出し元の実装（コンパイラによる網羅性の強制）
// —————————————————————–
async function executeApplicationWorkflow(userId: string) {
const result = await fetchUserProfile(userId);
// コンパイルタイムで分岐が強制される
if (!result.ok) {
// このブロック内では result.error は `ApiErrors` 型に完全にナローイングされる
switch (result.error._tag) {
case ‘NetworkError’:
console.error(`Network failed with status: ${result.error.statusCode}`);
// リトライロジック等の型安全な分岐
return;
case ‘ParseError’:
console.error(`Serialization corruption: ${result.error.message}`);
// フォールバック処理
return;
default:
// 網羅性チェック (Exhaustiveness Check)
const exhaustiveCheck: never = result.error;
return exhaustiveCheck;
}
}
// このブロック内では result.value は `UserProfile` 型として安全に利用可能
console.log(`Successfully loaded user: ${result.value.name}`);
}
—
4. チーフアーキテクトの視座：なぜこの設計が不可欠なのか
このアプローチを採用することで、以下の圧倒的なアドバンテージがもたらされる。
1. 暗黙の例外（Implicit Exceptions）の駆逐
TypeScriptの言語仕様上、JavaのようなChecked Exceptionは存在しない。そのため、通常の `async` 関数はどこでどんな例外をスローするかをシグネチャから読み取ることが不可能である。しかし、戻り値を `Promise
2. V8最適化とメモリ効率の維持
例外オブジェクト（`Error`）の生成は、スタックトレースのキャプチャを伴うためV8エンジンにおいて比較的重い処理である。想定されるドメインエラーを値として返す、あるいは `safeAsync` 内でフィルタリングすることで、無駄な例外インスタンスの生成とガベージコレクションの負荷を最小化する。
3. 網羅性チェック（Exhaustiveness Checking）による堅牢性
TypeScriptの `never` 型を用いた網羅性チェックにより、将来的に新しいエラー型（例: `DatabaseError` など）が追加された際、すべてのハンドリング箇所の修正をコンパイルエラーによって強制できる。これにより、リファクタリング漏れによる本番障害をゼロに収束させることが可能となる。
—
結び
型システムとは、開発者のための単なる「入力補完ツール」ではない。それは、実行時という混沌とした現実世界において、コードの論理的整合性を守り抜くための最後の防壁である。
`Promise