Michael Feathers氏の提唱する設計指針としてのエラー処理

Michael Feathers氏はエラーに関心を持っているが、ほとんどの開発者がエラーに多くの時間を割きたいとは思っていないことは理解している。氏はまた、大部分のエラー処理は一種のギブアップに過ぎない、と考えている。著書である“Working Effectively With Legacy Code”でも広く知られている氏は、Explore DDD 2018で行った基調講演の中で、エラーを排除することが、いかにソフトウェアシステム設計のドライバになり得るかを論じた。

ドメイン駆動設計のカンファレンスに相応しく、氏の講演は“ドメイン”についての５つの定義で始まった。これらの定義から氏が見つけた共通点は、ドメインとは範囲を意味するものであり、その多くは恣意的に決められたものである、ということだ。恣意的な創造物である以上、形を変えたり、拡張したりすることも可能なはずだ。進化するビジネスプロセスをモデル化し、それに適応する手段としてDDDを用いるのは直感的に思われるかも知れないが、Feathers氏は同じようなドメインの変更を、エラーにうまく対処し、場合によっては排除する手段とする方法を提唱する。

ドメインの拡張には注意が必要だ、なぜなら不調和(dissonance)を起こす可能性があるからだ、と氏は指摘し、その例として、2月30日を選択可能な日付とすることと、配列添字として負の値を指定可能なプログラミング言語について言及した。日付の場合は、単純なドメインモデルがこれを無効とせず、選択を許可している理由は理解に難くない。しかしながら、負の配列添字の場合は逆で、エラーを投げるべきだと考えられる。このようなテクニックが利用可能で、それを有効な構文として受け入れられる時に、それが役立つ状況があると理解できるのだ。

Feather氏のエラーに関する調査は、MicrosoftのMidoriオペレーティングシステム研究プロジェクトにおいて、特にエラーモデルを論じたJoe Duffy氏のブログから、インスピレーションの一部を得ている。“エラーモデルが答えようとしている基本的な疑問は、‘エラー’はどのようにプログラマやシステムのユーザとコミュニケーションするか、というものだ”、とDuffy氏は言う。一見単純なこの疑問は、おのずと“エラーとは本当は何なのかを定義する”という命題へとつながる。考察を進めたFeather氏は、最終的に“なぜエラーがあるのか？”という疑問に達する。別の言い方をするならば、“エラー”とは、ドメインにおける概念の不一致を表す言葉なのではないのか？

概念から現実的なエラー処理に話題を移すと、エラーが発生した場合の動作には、おもに3つのカテゴリがある。最初の選択肢は、単にnullを返すことだ。この方法では、何が問題だったのかという説明が除かれる、さらなるnull参照チェックが必要になる、エラーの処理中であるという事実が不明確になる、などの可能性がある。例外を投げる方法は、問題に関する情報を提供できるという点ではnullを返すより優れているが、呼び出し側がその例外を処理する必要がある。第3の選択肢は、エラーをドメインの一部にすることだ。Feathter氏は、“処理の一部として発生する可能性のあるエラーは、ドメインの一部である”という考えから、この選択肢を明確に支持する。

ドメインを拡張するということは、“本当に期待しているのは何か？”を問うことだ。誰かにエラーを伝えるだけでなく、実行可能な情報を提供する新たな概念を導入しよう。nullオブジェクトパターンを利用する、ItemNotFoundオブジェクトを返すなどの方法があるが、具体的な実装は状況によって異なる。

Feathers氏の提唱する最後の論点は、Erlangの設計思想である、英国のミーム形式でまとめるならば、“落ち着き払ってクラッシュする”ということだ。現実の世界では、計算処理は実際の世界に結び付いているので、計算が失敗する可能性がある。Erlangは、アプリケーションを世界の一部とすることで、そのドメインを拡張する。この方法で言語全体のドメインを拡張すえることができれば、小規模なシステムであれば確実に、エラーを包含するように拡張されたドメインのメリットを享受できる。