11月1日の学び(その②)

例外処理は真剣に考えると凄く難しい(そして面白い)。

例外処理の目的

  • 例外の回復
  • 例外の通知

例外の回復

  • 例えばDBのにアクセスできない場合にリトライするなど。
  • そもそも回復できるという保証はない。
  • その場合は呼び出し元に通知する。

例外の通知

  • 呼び出し側で例外の通知を受けた場合は、例外が発生する前にロールバックするのが望ましい。
  • その前提条件として、例外を通知する側が保証するべき条件が存在する。
  • それを例外安全と呼ぶ。

例外安全の保証レベル

上から順に強くなる。基本保証が満たされない場合は例外安全ではない。この場合例外発生時に何がおこるか制御不能となるため、その処理自体の利用をやめるべき

  • 基本保証:安全なソフトウェアを作るため(最低限満たすべきレベル)
  • 強い保証:例外回復するため
  • no-fail保証:言語や機構の要求されるため

基本保証

  • 例外が発生した場合に「オブジェクトの内部状態の整合性が保たれる」「オブジェクト内でリソースリーク(プログラムが割り当てたリソースを解放していない状態)が発生しないことを保証する
  • 例えばインスタンスの生成に失敗した際にメモリリークが起きないことなど
  • 基本保証だけでは例外発生時に回復(ロールバック)できない

強い保証

  • 例外が発生した場合に「オブジェクトの内部状態は一切変更されない」ことの保証。
  • これは「例外が発生した場合にロールバック可能であること」と同義。 -「例外発生時に副作用が発生しないこと」と同義
  • DBのトランザクション処理と同じ。
  • 強い保証が満たされていれば例外発生時に回復ができる。

no-fail保証

  • 足し算・引き算などのメソッド。
  • 処理が必ず成功することを保証する。
  • IO系の処理が絡むとno-fail保証は満たされない。
  • 言語や機構に要求されるレベルでの話。

www.techscore.com

qiita.com

例外中立

例外発生時に握りつぶしはダメ絶対。