例外が保持するプロパティ

コンテキスト

adr-004-例外のクラス階層に以下の課題が発見された。

  • データが正常に書き込まれたかの判定をすべてのロジックで考える必要が出てくる
  • リトライ可能、リトライ不可能が型の階層で定義されているため、同じ意味の例外を二つ作成しなくてはならない
    • 例えばサーバの例外クラスをリトライ可能とリトライ不可とで二つ定義する必要が出てくる

決定事項

クラス階層の変更

クラス階層を以下の内容に変更する。

  • RuntimeException
    • TISException
      • ServerException … サーバ起因の例外
        • (個々の例外クラス)
      • StoreException … Store起因の例外
        • (個々の例外クラス)
      • BusinessException … ビジネスロジック起因の例外
        • InternalException … 内部例外
        • (個々の例外クラス)

リトライ可能か不可能かは後述するコード値の種類で判断する方針とする。

プロパティ

TISExceptionが持つ共通プロパティからcompleted,occurredOnを削除する。よってプロパティは以下の一つになる。

・String code … コード値

データが正常に書き込まれたかは例外クラスのプロパティではなく、メソッドごとに例外がスローされた場合データが正常に書き込まれていない可能性があるかをドキュメントで定義する方針とする。例えば、findPerson関数で例外が発生した場合データの書き込み状態を気にする必要はないと記載する。一方、例外が発生した場合データが正常に書き込まれていない可能性があるメソッドではドキュメントにその旨を記載する。クライアントアプリケーションはメソッドごとに例外が発生した場合どのような処置が必要かをドキュメントから判断する。

コード値の種類を決定

TISExceptionが持つコード値の種類を以下に定める。(xの部分は任意の数字)

  • ServerException : Server_xxxx (サーバのエラーコードを直接使用)
  • StoreException : Store_xxx
  • BusinessException : Business_xxx

また、1桁目でリトライ可能か、不可能かをす。 1: リトライ可能 0: リトライ不可

例えばServer_1xxであればサーバ起因であり、リトライ可能であることを表す。

ステータス

受理

結果

本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。