有益な例外とクリーンなコードのバランスをとる良い方法は何ですか？

公開SDKでは、例外が発生する理由について非常に有益なメッセージを提供する傾向があります。例えば：

if (interfaceInstance == null)
{
     string errMsg = string.Format(
          "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.",
          ParameterInfo.Name,
          ParameterInfo.ParameterType,
          typeof(IParameter)
    );

    throw new InvalidOperationException(errMsg);
}

ただし、コードが何をしているのかではなく、エラーメッセージに重点を置く傾向があるため、コードの流れが煩雑になる傾向があります。

同僚は、次のようなものにスローする例外の一部をリファクタリングし始めました：

if (interfaceInstance == null)
    throw EmptyConstructor();

...

private Exception EmptyConstructor()
{
    string errMsg = string.Format(
          "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.",
          ParameterInfo.Name,
          ParameterInfo.ParameterType,
          typeof(IParameter)
    );

    return new InvalidOperationException(errMsg);
}

これにより、コードロジックが理解しやすくなりますが、エラー処理を行うための多くのメソッドが追加されます。

「長い例外メッセージの混乱ロジック」問題を回避する他の方法は何ですか？私は主に慣用的なC＃/。NETについて質問していますが、他の言語がそれをどのように管理するかについても役立ちます。

[編集]

それぞれのアプローチの長所と短所もあるといいですね。

なぜ特別な例外クラスがないのですか？

if (interfaceInstance == null)
{
    throw new ThisParticularEmptyConstructorException(<maybe a couple parameters>);
}

これにより、フォーマットと詳細が例外自体にプッシュされ、メインクラスが整理された状態になります。

Microsoftは（.NETソースを参照して）リソース/環境文字列を使用する場合があります。たとえば、ParseDecimal次のとおりです。

throw new OverflowException(Environment.GetResourceString("Overflow_Decimal"));

長所：

• 例外メッセージを一元化し、再利用を可能にする
• 例外メッセージ（おそらくコードには関係ありません）をメソッドのロジックから遠ざける
• スローされる例外のタイプは明らかです
• メッセージをローカライズできます

短所：

• 1つの例外メッセージが変更されると、すべてが変更されます
• 例外メッセージは、例外をスローするコードでは簡単に利用できません。
• メッセージは静的であり、どの値が間違っているかについての情報は含まれていません。それをフォーマットしたい場合は、コードがより乱雑になります。

パブリックSDKシナリオの場合、有益なエラー、静的チェックを提供し、XMLドキュメントに追加するドキュメントを生成したり、Sandcastleが生成したヘルプファイルを追加したりできるため、Microsoftコードコントラクトの使用を強く検討します。Visual Studioのすべての有償バージョンでサポートされています。

追加の利点は、顧客がC＃を使用している場合、コードコントラクト参照アセンブリを利用して、コードを実行する前でも潜在的な問題を検出できることです。

コードコントラクトの完全なドキュメントはこちらです。

私が使用するテクニックは、検証を組み合わせてアウトソーシングし、ユーティリティ関数にまとめてスローすることです。

最も重要な利点の1つは、ビジネスロジックで1つのライナーに削減されることです。

さらに削減できない限り、ビジネスロジックからすべての引数の検証とオブジェクト状態のガードを排除し、運用上の例外条件のみを維持することで、より良い結果が得られると思います。

もちろん、それを行う方法があります-強く型付けされた言語、「いつでも無効なオブジェクトを許可しない」設計、契約による設計など。

例：

internal static class ValidationUtil
{
    internal static void ThrowIfRectNullOrInvalid(int imageWidth, int imageHeight, Rect rect)
    {
        if (rect == null)
        {
            throw new ArgumentNullException("rect");
        }
        if (rect.Right > imageWidth || rect.Bottom > imageHeight || MoonPhase.Now == MoonPhase.Invisible)
        {
            throw new ArgumentException(
                message: "This is uselessly informative",
                paramName: "rect");
        }
    }
}

public class Thing
{
    public void DoSomething(Rect rect)
    {
        ValidationUtil.ThrowIfRectNullOrInvalid(_imageWidth, _imageHeight, rect);
        // rest of your code
    }
}

[注]コメントがある場合は、質問から回答にコピーしました。

各例外をクラスのメソッドに移動し、書式設定が必要な引数を受け取ります。

private Exception EmptyConstructor()
{
    string errMsg = string.Format(
          "Construction of Action Argument: {0}, via the empty constructor worked, but type: {1} could not be cast to type {2}.",
          ParameterInfo.Name,
          ParameterInfo.ParameterType,
          typeof(IParameter)
    );

    return new InvalidOperationException(errMsg);
}

すべての例外メソッドを領域に囲み、クラスの最後に配置します。

長所：

• メッセージをメソッドのコアロジックから除外します。
• 各メッセージにロジック情報を追加できます（メソッドに引数を渡すことができます）

短所：

• メソッドの混乱。場合によっては、例外を返すだけで、ビジネスロジックに実際には関係のない多くのメソッドが存在する可能性があります。
• 他のクラスのメッセージは再利用できません

もう少し一般的なエラーを回避できる場合は、ソースの型を推測するパブリックスタティックジェネリックキャスト関数を作成できます。

public static I CastOrThrow<I,T>(T t, string source)
{
    if (t is I)
        return (I)t;

    string errMsg = string.Format(
          "Failed to complete {0}, because type: {1} could not be cast to type {2}.",
          source,
          typeof(T),
          typeof(I)
        );

    throw new InvalidOperationException(errMsg);
}


/// and then:

var interfaceInstance = SdkHelper.CastTo<IParameter>(passedObject, "Action constructor");

SdkHelper.RequireNotNull()入力の要件をチェックし、失敗した場合にのみスローするバリエーションが考えられます（考えます）。ただし、この例では、キャストを組み合わせて結果を生成すると、自己文書化されてコンパクトになります。

.net 4.5を使用している場合、コンパイラーに現在のメソッド/ファイルの名前をメソッドパラメーターとして挿入させる方法があります（CallerMemberAttibuteを参照）。しかし、SDKの場合、おそらく顧客に4.5への切り替えを要求することはできません。

ビジネスロジックエラー（必ずしも引数エラーなどである必要はありません）に対して私たちがしたいことは、すべての潜在的なタイプのエラーを定義する単一の列挙を持つことです。

/// <summary>
/// This enum is used to identify each business rule uniquely.
/// </summary>
public enum BusinessRuleId {

    /// <summary>
    /// Indicates that a valid body weight value of a patient is missing for dose calculation.
    /// </summary>
    [Display(Name = @"DoseCalculation_PatientBodyWeightMissing")]
    PatientBodyWeightMissingForDoseCalculation = 1,

    /// <summary>
    /// Indicates that a valid body height value of a patient is missing for dose calculation.
    /// </summary>
    [Display(Name = @"DoseCalculation_PatientBodyHeightMissing")]
    PatientBodyHeightMissingForDoseCalculation = 2,

    // ...
}

[Display(Name = "...")]属性は、エラーメッセージを翻訳するために使用するリソースファイルでキーを定義します。

また、このファイルは、特定のタイプのエラーがコードで生成されるすべての発生を見つけるための開始点として使用できます。

ビジネスルールのチェックは、違反したビジネスルールのリストを生成する専用のValidatorクラスに委任できます。

次に、カスタム例外タイプを使用して、違反したルールを転送します。

[Serializable]
public class BusinessLogicException : Exception {

    /// <summary>
    /// The Business Rule that was violated.
    /// </summary>
    public BusinessRuleId ViolatedBusinessRule { get; set; }

    /// <summary>
    /// Optional: additional parameters to be used to during generation of the error message.
    /// </summary>
    public string[] MessageParameters { get; set; }

    /// <summary>
    /// This exception indicates that a Business Rule has been violated. 
    /// </summary>
    public BusinessLogicException(BusinessRuleId violatedBusinessRule, params string[] messageParameters) {
        ViolatedBusinessRule = violatedBusinessRule;
        MessageParameters = messageParameters;
    }
}

バックエンドサービスコールは、違反したビジネスルールをユーザーが読み取り可能なエラーメッセージに変換する一般的なエラー処理コードにラップされます。

public object TryExecuteServiceAction(Action a) {
    try {
        return a();
    }
    catch (BusinessLogicException bex) {
        _logger.Error(GenerateErrorMessage(bex));
    }
}

public string GenerateErrorMessage(BusinessLogicException bex) {
    var translatedError = bex.ViolatedBusinessRule.ToTranslatedString();
    if (bex.MessageParameters != null) {
        translatedError = string.Format(translatedError, bex.MessageParameters);
    }
    return translatedError;
}

これToTranslatedString()は、属性enumからリソースキーを読み取り[Display]、ResourceManagerこれらのキーを変換するために使用できる拡張メソッドです。各リソースキーの値は、のプレースホルダ含むことができstring.Format提供一致しますMessageParameters。resxファイルのエントリの例：

<data name="DoseCalculation_PatientBodyWeightMissing" xml:space="preserve">
    <value>The dose can not be calculated because the body weight observation for patient {0} is missing or not up to date.</value>
    <comment>{0} ... Patient name</comment>
</data>

使用例：

throw new BusinessLogicException(BusinessRuleId.PatientBodyWeightMissingForDoseCalculation, patient.Name);

このアプローチを使用すると、新しいタイプのエラーごとに新しい例外クラスを導入する必要なく、エラーメッセージの生成をエラーの生成から切り離すことができます。異なるフロントエンドが異なるメッセージを表示する必要がある場合、表示されるメッセージがユーザーの言語やロールなどに依存する必要がある場合に役立ちます。

この例のようにガード句を使用して、パラメーターチェックを再利用できるようにします。

さらに、ビルダーパターンを使用して、複数の検証をチェーンすることができます。それは次のように少し見ていきます流暢表明。