エラーハンドリングに関する私なりのガイドライン
いつからか、通信に関するプログラミングを行う機会が多くなった。通信が成功することは奇跡なので、様々な状況で、様々な原因により、エラーが発生し、失敗する。プログラミングにおいてエラーハンドリングは重要だが、ネットワークプログラミングでも同様である。
というわけで、エラーハンドリングに関する私なりのガイドラインを書いてみる。
エラーが発生したときに、プログラムがとりうる行動がいくつかある。「続行」「再試行」「中止」の三つだ。自動*1・手動*2でこれらを選択するという観点を持って、詳しく考えてみる。
- 続行 ( Ignore )
- 再試行 ( Retry )
- 原因が致命的でない場合、選択できるべきである
- 再試行すれば成功する可能性があるため
- プログラムで自動的に何度かこれを選択し、駄目だった場合にエラーダイアログを出すなどすると利便性が向上する
- ただし、後述する共通事項で述べることを熟考しておく必要があるので注意すること
- 時間の経過によって状況が改善され再試行対象処理が成功する可能性がある場合、自動再試行の有効性は大きい
- ただし、自動再試行は永遠に行うのではなく、自動再試行回数を制限する、自動再試行時間を制限する、その間何らかの方法で利用者がこれを中止できるようにするなどしなければならない
- 原因が致命的でない場合、選択できるべきである
- 中止 ( Abort, Cancel )
- 原因に関わらず、選択できるべきである
- これができないと利便性を損ねるため
- 原因に関わらず、選択できるべきである
- 共通事項
- プログラムが自動的に何らかを選択する場合、それを仕様として明確にし、実施前に利用者が把握できるようにしなければならない
- でなければ、これによって利用者が大きな不利益を被るなど、トラブルの元になる
- そのような可能性がある場合、利用者に逐一確認を求めるのが無難である
- プログラムが自動的に何らかを選択する場合、それを仕様として明確にし、実施前に利用者が把握できるようにしなければならない
開発対象となるプログラムに応じて、これらを適切に決定する必要がある。開発対象が Linux でいうデーモン、Windows でいうサービスならば、基本的に途中で選択肢を提示する、ということはない。代わりに、それらを設定ファイルなどで与えることで振る舞いを調整する。開発対象が GUI や CUI をもつ対話型のアプリケーションならば、途中で選択肢を提示し、利用者に選択してもらうことによって振る舞いを調整する。よくできたアプリケーションならば、それらの振る舞いをある程度記憶し、次回からはそれに沿った振る舞いをすることができたりする。
また、共通事項として記述したが、プログラムが自動的に選択を行う場合は、特に注意が必要である。例えば、それらの選択によって利用者への課金が発生する場合などである。直接的に課金が発生しないにしても、通信環境によっては料金体系が定額制でなく従量制である場合、十分な注意が必要である。これは、携帯端末などの移動体通信環境下においてはよくあることである。
プログラミングという分類としては抽象的な内容になってしまったが、以上がエラーハンドリングに関する私なりのガイドラインである。ご意見、ご指摘をいただければ幸いである。
