.NETの"例外"はシステム上(論理上)では想定されるエラーも含まれますが、予め想定されないエラーを処理するためにあるものと理解しています。"業務エラー"というものは予め想定されていますので、フロー上にも記述でき、広義でいえば正常系に含まれるものと言えます(考えます)。この点に関して、「更に検証メソッドを必ず用意して業務フローを確立する」というのであればまだわかるのですが、戻り値で表すというのは完全にNGです。例外とは、操作レベルの例外的事象を表すのであって、業務フローどうこうは無関係と考えます。最終的にはプレゼンテーション層で適切にハンドルされ、「業務フロー」に乗っかるわけですし。そのような可能性のある箇所に対しては、正常系(処理)、業務エラー(処理)を包含する形で例外(処理)を施すと考えます。当初業務エラーが発生しないと考えていたメソッドで、業務エラーが発生するとわかり、戻り値の型をvoidから列挙体Aにしたとします。それを受け取って処理する側の変更作業が抜けてしまった場合、処理の施しようがないかと思います。書きましたように困難なことです。業務エラーは、予め想定されていますのでもともと多くの情報を必要としないはずです。例外は、処理漏れが生じた際にそれを検出しやすくするようにと考えられたものだと思います。その際、その処理漏れについての詳細な情報を提供するために、例外は色々な情報を保持しています。処理漏れの可能性がある以上、例外の持つ情報が不要となることはないと考えます。ちなみにこの本では、例としてある口座からある口座へ指定した金額を移動させるメソッドを取り上げています。戻り値の型はvoidとし、「戻った場合は成功、失敗した場合は例外をスロー」としています。移動元の口座の残高が不足しているためお金を移動できない等のケースは例外として扱うと明示しています。正しくは、"例外"と断定せず、楽観同時実行により起こる状況を"業務エラー"として扱うかというビジネス上の判断により、SQLExceptionでキャッチして、"業務エラー"として処理すべきか、そのまま"例外"として処理すべきか決まるものだと思います。うーん、そもそもAAfNと赤間本では業務エラーの考え方が違うんですよね。AAfNでは、想定される・されないという区別はしていません。見てもらえばわかるとおり、私も想定される・されないという区別はしていません。赤間本を読んで「業務エラーを戻り値で表そう」という意見を持たれている方々は、恐らく想定する・しないで業務エラーを区別しているかと思います。それを少し取り上げました。「業務エラーは一般的に想定されるエラーと見なされる」という言い回しもそのためです。そもそも想定される・されないというのは、処理を行うメソッドが判断するのではなく、利用者側が判断することです。ビジネス層をコンポーネント化し、これをいくつかのアプリケーションから利用するとします。この時、その状況を想定する・しないは各アプリケーションに委ねられます。この例えはわかりやすく説明するためにビジネス層をコンポーネント化した場合を取り上げましたが、当然コンポーネント化に関わらず言える事です。29ブログ内検索カウンターアクセスカウンターおすすめプロフィールAuthor:よこけん性別は男です。生年月日は1984年2月頃です。社会人は2004年4月頃からやってます。C#は2004年10月頃からやってます。このブログは2006年7月頃からやってます。アプリケーションリンクopus-i商用可・加工可で、綺麗な素材を提供していらっしゃいます。紹介していらっしゃいます。中心に扱っていらっしゃいます。コマンドレットをまとめたスナップインです。クラスライブラリを作ってみました。最近の記事ブログ移転しました。返事を返せない場合があります。