エラーの分類とエラーハンドリング戦略
エラーの種類を簡単に。
- ビジネスロジックエラー(代替フロー)
- システムエラー
- 入力エラー
- プログラミングエラー
- 内部状態不整合エラー
- (他にある?)
ビジネスロジックエラー
ユースケースにおける、いわゆる代替フロー。
残高1000円なのに、2000円引き出そうとしたときの処理フローに相当
- 機能定義・論理設計・基本設計段階で洗い出される必要がある。
- 機能の一部として、エラー発生時の処理が明確に洗い出されている必要がある。
- アプリケーションは、エラー内容に応じた処理を実行するように実装されている必要がある。
システムエラー
動作環境などが正常に動いていない場合のエラー
ATMシステムで、ATMとバックエンドシステムのネットワークが疎通していない場合や、バックエンドシステムにおいて、RDBMSが動作していない場合などに相当
- 基本設計・詳細設計段階で洗い出されている必要がある。
- 要件にも依存するが、致命的エラーであることをユーザーに通知できれば良い。エラーの種別毎に処理を行うなどは求められないケースが多い。
- 適切に不具合情報を入れ込んだロギングが重要。
- 2重化など、システムエラーが起こる原因自体を排除するor発生頻度を低める取り組みについては、ここでは触れない。
入力エラー
いわゆるvalidationエラー。入力したデータが、まずい場合
(機能定義・)論理設計・基本設計段階で洗い出される必要がある。
- 金額入力欄にアルファベットが入力された場合など
- (ビジネスロジックと同様?)
プログラミングエラー
API・クラスライブラリ・フレームワーク・ユーティリティクラスを適切に使用していないために生じるエラー。
基本的に、詳細設計・プログラミング作業中にしか発生しない。
- 結合テストにおいてこのエラーの発生する可能性を可能な限り低めるような努力がなされていなくてはならない。
- DAOにConnectionをsetせずにfindXXX()メソッドを呼んだ場合など
内部状態エラー
主に2種類あると考える（もっとあるかも）
- システムが保持するデータの不整合
- マスタ不一致エラーとか
- 主に運用のミスによる
プログラムのロジックバグにより、満たされているべき前提条件が満たされなくなったため発生するエラー
- たいていの場合DAOにConnectionがキチンと設定されるが、特定の処理を実行するとDAOにConnectionが設定されなくなり、nullPointerExceptionが発生する
- 設計・テスト段階で洗い出しに失敗したプログラミングエラーが顕在化したケースと考えることが出来る。
要件にも依存するが、致命的エラーであることをユーザーに通知できれば良い。エラーの種別毎に処理を行うなどは求められないケースが多い。
- 適切に不具合情報を入れ込んだロギングが重要。
- (システムエラーと同様?)
フェーズとエラー種別とエラーハンドリング
フェーズとエラー種別により、適切なエラーハンドリング戦略は異なる。 プログラミングフェーズで好ましいエラーハンドリングと、保守・運用フェーズで好ましいエラーハンドリングは異なる。そもそも出るエラーの特性がまったく異なるのだから、乱暴な比較ではあるのだけれども。
すくなくとも、エラーハンドリングの目的が、「機能仕様を満たす」ことか、それとも、次のアクションを起こしやすくするための単なる「情報提供」か、で、求められる戦略が異なる点は留意したほうが良い。
ツッコミは愛をこめて。
artonさんの日記のやりとりに刺激されて、妄想含みで書いてみた。乱文失礼。
