例外をスローする際の考慮事項

同僚が、彼が苦労しているコードを含むメールを送ってきました。彼はtry/catchesを使ってビジネスロジックを駆動することを避けようとしています。

問題はtry/catchesではなく、単にその問題の症状です。問題が見つかりますか？いくつかの仮定を立てる必要がありますが、あなたも私と同じ結論に達すると確信しています。

以下がコードです。無実の者を保護するために変更しました：

private Customer GetOrCreateCustomer(long customerTelephoneNumberOrCustomerId)
        {
           Customer customer;
            try
            {
                customer = this.DoMagic(customerMasterTelephoneNumberOrCustomerId);
            }
            catch (DataException)
            {
                try
                {
                    //TODO: I know this isn't ideal. Still thinking of a better way to do this. 
                    customer = this. GetCustomer(customerMasterTelephoneNumberOrCustomerId);
                }
                catch (DataException)
                {
                    customer = this.GetCustomerFromExternal(customerMasterTelephoneNumberOrCustomerId);
                    customer.CustomerId = this.CreateCustomer(customer);
                }
            }

            return customer;
        }

このシステムには、nullは悪いという根本的な哲学があります。ほとんどの場合、nullが生成される可能性がある場所では例外がスローされます。最初は、これに問題があるとは思いませんでした。アーキテクチャの決定、美学だと思っていましたが、コードと連携するにつれて、これはアーキテクチャの誤りであることが明らかになりました。

なぜnullの場合に例外をスローすることが悪いのかと思うかもしれません。

以下は、例外をスローすることを検討する際のガイドラインです：

1. nullをチェックして例外をスローする必要があるという事実は、それが必要ないというヒントになるはずです。それは予期された結果であり、したがって例外ではありません。
2. 例外をスローすることはリソース集約的な操作であり、.Netで実行できる最もリソース集約的な操作の1つです。
3. exceptionはまさにそれです。例外です。コードで立てられた仮定に対する例外です。これらの仮定が破られると、システムは終了する必要があります。システムが不明な状態にあるため、先に進むことはできません（例えば、データベースが利用できなくなっています）。これは攻撃ベクトルにもなる可能性があります。
4. 例外をスローするということは、ビジネスルールを強制するために上流の呼び出しをtry/catchブロックでラップする必要があるということです。null値は、アプリケーションのフローを制御するためのビジネスの機会です。null値に対するアクションは、ビジネス上の決定を下す必要がある時点で実行する必要があります。例えば、顧客変数がnullの場合、UIレイヤーでユーザーに「IDが’1234’の顧客が見つかりません」というメッセージが表示されます。