2013-01-15 5 views
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); 
    } 
} 

私は、上記の泡立ちとハンドリングやロギングの正しい道をたどるのですか?私がいる限り2つの条件が満たされているとして、これを行うためのあなたの方法に同意に傾いている

+2

johnのスケルトンによると、パフォーマンスは例外のスローによってほとんど影響を受けません。参照してください:http://www.developerfusion.com/article/5250/exceptions-and-performance-in-net/ – albertjan

+2

例外は例外的なものでなければならないので、大したことですか? – emartel

+0

@albertjan私はJon Skeetに同意します。しかし、私のアプローチは正しい方法で対処し、ログに記録していますか? – Billa

答えて

3

  1. あなたLogger.Log

    はあなたがここに示されたものよりも便利な、より意味のあるものを/ログ(私はここにあなたのコードを推測しているのは、エラーが記録されたことを示すサンプルメッセージです)。あなたが例外の原因を追跡するのに使うことができる情報があれば、良い。
  2. あなたの//show error msg to userのコメントは、その場所で、エラーが発生したことを説明し、デフォルトの例外画面/ strackトレースを表示しているだけではないことを示しています。

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

1

例外の大まかなルールでは、「何かを行う」ことができない限り、値を追加することはできません。理想的には、これは、ユーザが困ったことを知らないという点で、何らかの優雅な回復になりますが、最低限、あなたがやっている例外を記録することを含むでしょう。

ただ例外をキャッチしてすぐに再スローしないでください。それは価値がない。 (これに対する例外は、例外のタイプを文脈に対してより有益/適切なものに変更する必要がある場合などです)。

+0

彼は何か(それを変更したり情報を記録したりする)例外を捕まえて*再*投げているが、何もしないようにキャッチするのではなく、同じ例外を再投げているので、これは当てはまりません。 – Servy

+0

catch-then-rethrowコードは、「catch、log、throw new exception」ブロックの1つの特定のタイプの例外をフィルタリングするためだけに存在します(このタイプの例外は、ログされました)。 – yoozer8

+0

@Servyいいえ、彼はそれを捕まえて、それをもう一度投げる以外に何もしていませんでした。彼は、意図的に何もしない理由と、なぜ「それはすでに記録されている」の両方を述べているコメントをそこに置いています。 –

1

例外を投げてキャッチするのは、通常のリターン機構に比べて高価ですが、それ以外の点では例外です。通常の制御フローメカニズムとして例外を使用するのではなく、例外的な処理を行います。

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

私はあなたのリードが「これは間違っている」と言うなら、「私たちのエラー処理戦略は何ですか?」と尋ねるのは公正だと思います。コードがどのような目的を果たしているのか分からない場合、どうすれば偉大なコードを提供することができますか?

0

あなたのアプローチに間違いはありませんが、カスタム例外が多くの価値を追加することはありません。ユニークなキー違反などの特定のSQL例外をカスタム例外にラップして、UIに意味のあるエラーメッセージが表示される可能性がある場合は、DALで例外をラップすると値が追加される可能性があります。

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

+0

私はいつも同じように聞こえる、それは非常に悪い影響を持っていますが、あなたの言うことによると、おそらくそれはデバッグ中にのみ影響を与えます...投げる前に多くのチェックをしている人の横に、タイムアウトがあります。まだ、最初の人が正しいと思って、私は例外が来て、私は特定の種類の例外に変更する前に、全体のアプリケーションの例外と混在する前に、それをキャッチし、新しいインスタンスを再作成し、それはパフォーマンスを向上させる投げの方法はありますか? – deadManN

+1

Jon Skeetの最初のコメントのリンクを読んで、例外とパフォーマンスをよりよく理解することができます(http://www.developerfusion.com/article/5250/exceptions-and-performance-in-net/)。私の意見では、ほとんどのアプリケーションでは、アプリケーションには意味があり、パフォーマンスについては心配しないで例外を処理する必要があります。 –

関連する問題