try catchの使用

Question

コードスニペット1またはコードスニペット2はどれですか？なぜ？

/* Code Snippet 1 
* 
* Write try-catch in function definition 
*/ 
void Main(string[] args) 
{ 
    AddMe(); 
} 

void AddMe() 
{ 
    try 
    { 
     // Do operations... 
    } 
    catch(Exception e) 
    { 
    } 
} 

/* Code Snippet 2 
* 
* Write try-catch where we call the function. 
*/ 
void Main(string[] args) 
{ 
    try 
    { 
     AddMe(); 
    } 
    catch (Exception e) 
    { 
    } 
} 

void AddMe() 
{ 
    // Do operations... 
} 

Answer 1

本当の質問は「他の世界へのAddMeの契約は何ですか？」です。 AddMeがすべてのインターフェイスのdo-allを表し、適切な方法で遭遇した例外を正しく処理する場合は、確実にそれをキャッチします。 AddMeが例外を処理するかどうかわからない場合、呼び出しコードに処理をスローして遅延させる必要があります。

Answer 2

これは通常通りです。

スニペット＃1では、エラー処理は再利用可能です。スニペット＃2ではそうではありませんが、別の場所でさまざまなエラー処理を使用する場合にはこれが優れています。

それ以外は同じです。

Answer 3

これらは同じように動作しますが、ほとんどの場合、メソッド内のロジックをキャッチする方が好きです。しかし、ベストプラクティス。

Answer 4

最も普遍的な方法はありません。あなたの例外をどのように処理するかによって異なります。

メインアプリケーションでグローバルロガーを使用する予定ですか？メインメソッドにtry/catchブロックがあり、そこに例外を記録する必要があります。

例外で他の処理を行う必要がある場合でも内部メソッドをキャッチすることはできますが、再試行することを忘れないでください。そうしないと、メインメソッドのロガーはログに記録されません。前者は、すべてのスタックトレースを保持しているため、後者はそうではない、

throw e; 

：

throw; 

ない：

と覚えては、使用、正しく再スローします。

Answer 5

IMHO、例外をスローするメソッドを許可します。物事がうまくいかないときは隠さないでください。彼らがそうするとき、彼らは例外をどのように処理したいのかを決定するのはクライアントに任されています。この理由は、各アプリケーションが例外とは異なる処理を実行する可能性があるためです。

Answer 6

この質問にはすでに良い回答がありますが、最終的には「それは依存しています」に至りましたが、どのような状況でどの方法が優れているかが大きな影響を及ぼすと考えています。

コードスニペットの例では、キャッチフレーズでは、catch (IOException e)またはcatch (NullReferenceExceptionなどの狭い例外タイプとは対照的に、キャッチがcatch (Exception e) {}であるとします。 tryブロック内のコードから予想される例外の種類によって、処理する方法が異なります。特に、サブルーチン外で例外を処理する場合には、複数のタイプを考慮する必要があります。十分に大きい上位レベルのtryブロックには、いくつかの異なるタイプの例外を処理して、コードが乱雑になります。

一般的には、例外が重大ではないエラー（特に無効なユーザー入力によるもの）の場合、サブルーチンで処理してシステムを実行し続けることができます。一方、例外がプログラムを閉じる必要があることを意味する場合、私はそれをより上に処理します。

Answer 7

TL、DR;例外に関して何かできることがあれば、例外をキャッチします。そうでなければ、何かがコールスタックを処理して処理するまでコールスタックを流れさせます。アプリケーションの特定の部分で例外を処理できない場合は、アプリケーションエラーイベントメソッドがすべてのログを処理する必要があります。あなたのロギング機能は、例外を処理するための最終的なネットになります。

私は、すべてのメソッドでtry catchロジックを必要とするいくつかのショップで働いていますが、Exceptionオブジェクトはできるかぎりあなたのコールスタックを見ている方が優れていることを学びました。

私の他の経験則は、ユーザトリガイベントに関する例外をユーザに通知します。したがって、イベントベースまたはコマンドベースのキャプチャは、同じ例外をキャッチし、通知してから再スローするのに適しています。 （IEスロー; exをスローしない;）