10

私はアプリケーションで例外を処理するこの方法に従いました。しかし、私のリーダーは、私がそれを間違っていると言いました。同じ例外をラップして再スローしているだけなので、パフォーマンスに影響します。

私のアプローチの何が問題になっていますか？ここで例外をログに記録して処理する方法について何か提案はありますか?

public class BusinessRepository : IBusinessRepo
{
    public List<Employee> GetEmployees()
    {
        try
        {
            //do some DB operations
        }
        catch (SQLException sqlex)
        {
            Logger.Log("Exception detail with full stack trace");
            throw new DALException(sqlex, "Error in data access layer");
        }

    }
}
public class BusinessLayerClass : IBusinessLayer
{
    private readonly IBusinessRepo Repo;
    public BusinessLayerClass(IBusinessRepo rep)
    {
        Repo = rep;
    }
    public List<Employee> GetEmployees()
    {
        try
        {
           List<Employee> emps= return Repo.GetEmployees();
        }
        catch (DALException dex)
        {
            //do nothin as it got already logged
            throw;
        }
        catch (Exception ex)
        {
            Logger.Log(ex, "Business layer ex");
            throw new BusinessLayerEx(ex);
        }
    }
}

public class HomeController : Controller
{
    public ActionResult Index()
    {
        try
        {
            List < Employee >= BusinessLayerClass.GetEmployees();

        }
        catch (DALException)
        {
            //show error msg to user
        }
        catch (BusinessLayerEx)
        {
            //show error msg to user
        }
        catch (Exception ex)
        {
            Logger.Log();
            //show error msg to user
        }
        return View(emps);
    }
 }

上記のバブリングと処理、およびロギングの正しい方法に従っていますか?

4

4 に答える 4

3

2つの条件が満たされている限り、私はこれを行うあなたのやり方に同意する傾向があります:

  1. あなたのLogger.Logステートメントは、ここで示したものよりも意味のある/有用なものをログに記録します (ここでのコードは、エラーがログに記録されたことを示すサンプル メッセージにすぎないと思います)。例外の原因を追跡するために使用できる情報が提供されている場合は、それで問題ありません。
  2. あなたの//show error msg to userコメントは、その場所で、エラーが発生したことを説明する素晴らしいビューをレンダリングすることを意味し、デフォルトの例外画面/ストラック トレースを表示するだけではありません。

throw;投げたばかりの DALException をキャッチする限り、それで問題ありません。ここでの目標は、前のレイヤーから出てくる例外をキャッチしてログに記録し、後で独自の例外をスローすることです。DALException は、既に別のエラーを記録して自分でスローした場合にのみスローされるため、このレベルを超えてバブルアップしてもまったく問題ありません。

于 2013-01-15T18:20:05.910 に答える
1

例外の一般的な経験則は、「それについて何かをする」、つまり付加価値がない限り、例外をキャッチしないことです。理想的には、これは、ユーザーが一時的な中断があったことを決して知らないという、ある種の優雅な回復ですが、少なくとも、これには、実行している例外のログ記録が含まれます。

すぐに再スローするためだけに例外をキャッチしないでください。それは何の価値もありません。（これに対する例外は、例外のタイプをより有益でコンテキストに適したものに変更する必要がある場合です）。

于 2013-01-15T18:25:51.730 に答える
1

例外のスローとキャッチは、通常の戻りメカニズムに比べてコストがかかりますが、それは要点から外れています-例外を通常の制御フローメカニズムとして使用するのではなく、例外的なことを処理するために使用することになっています。

例外処理は、技術的に非常に難しい場合があります。結局のところ、ほとんどの場合、私たちはそれらをまったく期待していません。しかし、例外処理を「正しく」行うことがほぼ不可能になるのは、チームまたはプロジェクトにエラー処理のための戦略がまったくない場合です。理想的な世界では、最初にどのような種類のエラー条件に対処する必要があるかを正確に把握し、それらを念頭に置いてアプリケーション全体を設計します (また、心に留めておく必要のある無数の他の制約とともに、コードの読みやすさからパフォーマンスまで)。

あなたのリーダーが「これは間違っている」と言った場合、「エラー処理戦略は何ですか?」と尋ねるのは当然だと思います。コードがどのような目的を達成することになっているのかもわからない場合、どうすれば優れたコードを提供できるでしょうか?

于 2013-01-15T18:44:59.103 に答える
0

あなたのアプローチには何も問題はありませんが、カスタム例外が大きな価値をもたらすとは思いません。DAL で例外をラップすることで付加価値が得られる例としては、固有キー違反などの特定の SQL 例外をカスタム例外でラップして、UI に意味のあるエラー メッセージを表示できるようにする場合があります。

パフォーマンスに関しては、非常に悪いことがすでに起こっているため、とにかく問題ではありません。

于 2013-01-15T19:34:08.487 に答える