エラー時に取り得る処置

処理は1つとは限らない。複合している可能性もある。

何もしない。

ログを出力する。

リソースを解放する。

上層にエラー、例外を渡す。

別のエラー、例外に変換して上層に渡す。

利用者向けのメッセージを組立てて上層に渡す。

利用者にメッセージを出力する。

再実行する。

すぐに再実行する。

入力を見直して再実行する。

ある程度の時間待って再実行する。

処理を一時停止して、続行するか中止するか、ユーザーの判断を待つ。

処理をキューイングして、次回に回す。

代替処理を行う。

処理を中止する。

処理前の状態にロールバックする。

状態をリセットする。

停止する。

スレッドを停止する。

プロセスを停止する。

サービス(プロセスグループ)を停止する。

システムを停止する。

再起動する。(停止して別のインスタンスとして起動)

プロセスを再起動する。

サービス(プロセスグループ)を再起動する。

システムを再起動する。

迷う点

エラー時にそもそも何をすべきかで迷う。

最も単純なのは、何もしないこと。

しかし、そのまま進むとシステムが破壊される可能性が高い。

次に簡単なのは、エラー値を返して終了すること。

エラー原因がはっきりしない。

ログを出して欲しいが、ログを出すと大量に出て止まらないという現象が起こる事がある。

同じログが繰り返されるなら、抑制することが考えられる。

そもそもどこにエラーメッセージ、ログを出すべきかがはっきりしない。(標準エラー出力か、syslog か)

エラーコード方式か例外方式かで迷う。

下層から返ってきたエラーが一時的なエラー(再実行可能)なのか恒久的なエラーなのか区別が付かない。

強制終了していいかどうかで迷う。

リカバリの方法に取り決めがなく、死んだらそのままになってしまう。

死んだ後再起動してもまた同じエラーで死んでしまう。

死ぬ時にシステム再起動していいかかどうかで迷う。

他の正常処理が巻き込まれすぎる。

死んだ理由がはっきりしないため、再起動していいかどうかで迷う。

事態をよけいに悪化させることがある。

データが破壊されるかもしれない。

データが破壊された後、そのデータは取り返せないかもしれない。

バックアップできればいいが、全体バックアップは時間的に困難、部分バックアップは範囲が不明瞭。