0

他のプロジェクトから呼び出されることを意図したいくつかのデータベースアクションのために、1つのプロジェクトでパブリック関数を作成しています。コードを書くだけで、次のアプローチをとることができます。

public int GetCount(Apple apple, Orange orange)
{
    try 
    { 
       // query; 

       return 1000;
    } 
    catch 
    { 
        // log it
        return -1; 
    }
}

また

public int? GetCount(Apple apple, Orange orange)
{
    try 
    { 
       // query; 

       return 1000;
    } 
    catch 
    { 
        // log it
        return null; 
    }
}

また

public bool GetCount(Apple apple, Orange orange, out int count)
{
    count = -1;
    try 
    { 
       // query; 

       count = 1000;
       return true;
    } 
    catch 
    { 
        // log it
        return false; 
    }
}

私は現在、次のような他のビジネスオブジェクトに対して「null」の方法を実行しています。

public Apple GetApple(Orange orange)
{
    try 
    { 
       // query; 

       return apple;
    } 
    catch 
    { 
        // log it
        return null; 
    }
}

そして、呼び出し元は、返された値がであるかどうかを確認し、nullそれに応じてエラーメッセージをポップします。そのため、値型の戻り型としても使用する傾向があります。int?しかし、私はこれらのものの許容可能な設計または奨励された実践が何であるかを知りたいです。

編集：呼び出し元の周りにtry catchを配置すると、コードベースにtry catchが散らかったままになりませんか？呼び出し先からの例外をキャッチして、それを呼び出すすべての関数が気にする必要がないようにする方が簡単ではありませんか？呼び出し先がエラーをキャッチし、呼び出し元にエラーが発生したことを通知した場合、何が問題になりますか？

4

4 に答える 4

4

例外を飲み込むのは悪い習慣です。

メソッドで例外を処理できない場合は、呼び出し元に例外をバブルします。

public int GetCount(Apple apple, Orange orange)
{
    try 
    { 
       // query; 

       return 1000;
    } 
    catch 
    { 
        // log it
        throw;
    }
}
于 2013-02-09T12:12:04.260 に答える
4

まあ、それは非常に主観的であり、標準化された答えは得られませんが、規則を開発するための優れたリソースであるフレームワーク設計ガイドラインExceptionの本は、「またはなどの非特定の例外をキャッチすることによってエラーを飲み込まないでください」と述べていますSystemException。それを飲み込んで、を含む魔法の値を返すとnull、システム障害の根本的な理由を認識できなくなります。

個人的には

public int GetCount(Apple apple, Orange orange)
{
    try 
    { 
       return // query; 
    } 
    catch 
    { 
        // log it
        throw;
    }
}

もう1つの個人的なポイント-システムが機能していない理由を理解するために診断とデバッグに多くの時間を費やし、最終的には、例外がサイレントにログに記録されて飲み込まれたことを確認しました。のようなコードに遭遇したとき、今私はとても苦痛を感じていcatch(Exception e) { return null; }ます。

于 2013-02-09T12:17:26.953 に答える
1

intドメインにとって明らかに正当ではない値を提供し、default<int>ゼロ以外のものである必要がない状況では、に利点はありませんNullable<T>。Nullable<int>nullをテストしてから、使用する前に他の保存場所に値を抽出する必要があるため、これらの型は呼び出し元が操作するのが面倒です。次のようなことを間違えた場合：

if (res.HasValue)
  for (i=0; i<res.Value; i++)
    ....

その場合、ループのオーバーヘッドは、それがあった場合の2倍以上になる可能性があります。

if (res.HasValue)
{
  int resValue = res.Value;
  for (i=0; i<resValue; i++)
    ....
}

しかし、不条理なレベルのループオーバーヘッドを回避するために、呼び出し元に追加の変数を作成するように要求するのは面倒なようです。

于 2013-02-11T14:31:03.947 に答える
0

私も使いint?ます。これは、ステータスを識別するために特定の番号を予約するのではなく、すべての番号を使用するのに役立つことに注意することが重要です。

これは、ステータスを伝えるために整数を使用し、誤って特別な使用のために数値を予約するものCと欠如です。C++

于 2013-02-09T12:13:26.457 に答える