Svelte入門：SvelteKitでのエラー処理 -Vol.4-

よっしー

こんにちは。よっしーです(^^)

今日は、SvelteKitでのエラー処.理について解説しています。

背景
エラー処理
Responses
Type safety
おわりに

背景

SvelteKitでのエラー処理について調査する機会がありましたので、その時の内容を備忘として記事に残しました。

エラー処理

エラーはソフトウェア開発において避けられない事実です。SvelteKit は、エラーの発生場所、エラーの種類、受信したリクエストの性質に応じて、エラーを異なる方法で処理します。

Responses

handle 内部や +server.js リクエストハンドラ内でエラーが発生した場合、SvelteKitはリクエストの Accept ヘッダーに応じて、フォールバックエラーページまたはエラーオブジェクトのJSON表現で応答します。

フォールバックエラーページは、src/error.html ファイルを追加することでカスタマイズできます：

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8" />
        <title>%sveltekit.error.message%</title>
    </head>
    <body>
        <h1>カスタムエラーページ</h1>
        <p>ステータス: %sveltekit.status%</p>
        <p>メッセージ: %sveltekit.error.message%</p>
    </body>
</html>

SvelteKitは %sveltekit.status% と %sveltekit.error.message% を対応する値に置き換えます。

ページのレンダリング中に load 関数内でエラーが発生した場合、SvelteKitはエラーが発生した場所に最も近い +error.svelte コンポーネントをレンダリングします。+layout(.server).js の load 関数内でエラーが発生した場合、ツリー内の最も近いエラー境界は、そのレイアウトの上にある +error.svelte ファイルです（隣ではありません）。

例外は、ルートの +layout.js または +layout.server.js 内でエラーが発生した場合です。通常、ルートレイアウトは +error.svelte コンポーネントを含むためです。この場合、SvelteKitはフォールバックエラーページを使用します。

これらの動作は以下のような利点があります：

フレキシビリティ：異なるタイプのリクエストに対して適切な形式（HTMLまたはJSON）でエラーを返すことができます。
カスタマイズ可能性：開発者は src/error.html を使用してグローバルエラーページをカスタマイズでき、アプリケーションのブランディングやデザインに合わせることができます。
細粒度のエラーハンドリング：+error.svelte コンポーネントを使用することで、アプリケーションの特定の部分に対してカスタムエラー表示を実装できます。
適切なエラー境界：レイアウトファイルでエラーが発生した場合、SvelteKitは適切なレベルでエラーをキャッチし、ユーザーエクスペリエンスを損なわないようにします。
フォールバックメカニズム：ルートレイアウトでエラーが発生した場合でも、フォールバックエラーページによって最低限の情報を表示できます。

これらの機能を活用することで、開発者はエラー処理と表示を細かく制御し、ユーザーに適切な情報を提供しながら、アプリケーションの堅牢性を向上させることができます。

Type safety

TypeScriptを使用していて、エラーの形状をカスタマイズする必要がある場合、アプリケーション内で App.Error インターフェースを宣言することでこれを行うことができます（慣例的には src/app.d.ts で行いますが、TypeScriptが「見える」どこにでも配置できます）：

src/app.d.ts

declare global {
  namespace App {
    interface Error {
      code: string;
      id: string;
    }
  }
}

export {};

このインターフェースには常に message: string プロパティが含まれます。

この機能の重要なポイントと利点は以下の通りです：

タイプセーフティ：カスタムエラープロパティを定義することで、アプリケーション全体でエラーオブジェクトの一貫した使用を保証します。
拡張性：アプリケーションの要件に応じて、追加のプロパティ（この例では code と id）を定義できます。
開発者エクスペリエンス：IDEやエディタが適切な自動補完と型チェックを提供できるようになります。
エラーハンドリングの一貫性：すべてのエラーオブジェクトが同じ構造を持つことを保証し、エラー処理ロジックを簡素化します。
ドキュメンテーション：インターフェース自体が、アプリケーション内でのエラーの構造に関するドキュメントとして機能します。

使用例：

import { error } from '@sveltejs/kit';

// エラーを投げる
throw error(404, {
  message: 'ページが見つかりません',
  code: 'NOT_FOUND',
  id: 'error-001'
});

// エラーを処理する
try {
  // some code that might throw an error
} catch (e) {
  if (e instanceof Error) {
    console.log(e.message); // TypeScriptは `message` プロパティの存在を知っています
    console.log(e.code);    // TypeScriptは `code` プロパティの存在を知っています
    console.log(e.id);      // TypeScriptは `id` プロパティの存在を知っています
  }
}

この方法でエラーの型を定義することで、アプリケーション全体でより堅牢なエラーハンドリングとタイプセーフなコードを実現できます。また、将来的にエラーオブジェクトの構造を変更する必要が生じた場合も、TypeScriptがどこで変更が必要かを教えてくれるため、リファクタリングが容易になります