Error ハンドリング戦略
JavaScript/TypeScriptの例外ハンドリング戦略を考える
例外設計についてまとめる
例外設計を行う時はまずは例外を業務エラーとシステムエラーに分類することから考えていく。
例外というのはすべて、何かしらのリカバリーを考える必要がある。
アプリケーションがクラッシュするとは
アプリケーションがクラッシュする場合、一般的にはエラーがキャッチされずに実行コンテキストから外れることが主な原因
具体的な条件としては以下のようなケースが考えられる。
-
エラーが発生し、そのエラーがトップレベルのエラーハンドラーに到達しない場合 エラーが発生しても、エラーハンドリングが適切に行われていない場合に起こります。エラーがキャッチされず、処理の制御が外部に移されるため、アプリケーションはクラッシュします。
-
非同期処理のエラーが処理されずに実行コンテキストから外れる場合:非同期処理(例: Promiseのrejectやコールバック関数内のエラー)が発生し、エラーハンドリングが適切に行われない場合に起こります。非同期処理内でエラーが発生し、そのエラーがキャッチされずに処理の制御が外部に移されると、アプリケーションはクラッシュします。
-
例外がスローされ、キャッチされずに実行コンテキストから外れる場合:JavaScriptの
throw
文を使用して明示的に例外をスローし、その例外がキャッチされずに処理の制御が外部に移されると、アプリケーションはクラッシュします。
Node.jsでは、未処理の例外がキャッチされなかった場合、デフォルトの動作としてアプリケーションが終了し、スタックトレースやエラーメッセージが出力されます。
したがって、アプリケーションがクラッシュしないようにするためには、エラーハンドリングを適切に行い、エラーがキャッチされるようにすることが重要です。例外やエラーをキャッチして適切な処理を行うことで、アプリケーションの安定性を確保することが可能。
例外の分類
大きく分けると2つ
- 正常系 目的の出力や副作用を得ることができる系
- 業務エラー
- 准正常系(想定内) 異常系であるが、仕様どおりに正常系への回復動作が実行される。 あるいは、仕様どおりにプロセスが終了する系(異常系だが想定内だと準正常系になる)
- システムエラー(500番)
- 異常系 目的の出力や副作用を得ることができない系
業務エラー
主にユーザの誤入力・誤操作が原因
- 指定フォーマットの違い(メールアドレスなど)
- 一意チェック(ユーザの重複など)
- 必須項目の存在
業務エラー対処方法
業務エラーとは主にユーザーの誤入力・誤操作が原因のエラーであり、その対処方法としてはユーザーに誤入力・誤操作を取り消してもらい、正常な入力・正常な操作を行ってもらう事が対処方法になる。 その為には正常な入力・正常な操作を行ってもらえるような例外(エラー)を考えていく必要がある。 正常な入力・正常な操作を行ってもらうには、まず何が誤入力・誤操作だったのかをユーザーに指摘する事が考えられるでしょう。 たとえばメールのフォーマットが違う場合、『エラーが起きました。』のような抽象的なメッセージを表示するのではなく、『不正なメールのフォーマットです。』のような具象的なメッセージを画面を用いて表示させる事が適切です。
システムエラー
システムエラーはユーザー側でどうにもできないエラーというメッセージ(いわゆる「500エラー画面」) を表示する。
- サーバが停止している
- データベースに接続できない
- プログラムのバグ
システムエラー対処方法
システムエラーとは主にユーザー側で対処できないエラーです。
たとえばプログラム内部のバグが原因でエラーが起きたとしましょう。
その時はシステム開発者がプログラムを修正する事が対処方法になります。
ユーザー側はバグを修正することは不可能な為、開発者にエラーが発生した詳しい状況を伝えてもらえるような画面を表示する必要がある。
また、バグが原因のエラーが発生した後にプログラムを実行してしまうと以降のプログラムの実行結果が正しいことが保証できない為、安全に終了してもらう必要があります。
開発者側は、システムエラーが起きたときに素早く対処できるように、ログにエラー内容を出すようにしましょう。
または、Errbitなどのエラー監視サービスを導入し、Slackなどと連携しておくとエラー時に迅速な対処が行えるでしょう。