24

重複の可能性:
ネストされた Try/Catch ブロックは悪い考えですか?

現在、try catch 内で try catch を使用していますか? 現在のシナリオでは、アプリケーションでそれが必要です。

void MyFun()
{
    try
    {
        //Process logic 1
        // ......
        try
        {
            //Process logic 2
            // ......
        } catch (Exception ex)
        {
            //write an error details in database
        }

        //Process Logic 3
        // ......

    } catch (Exception ex)
    {
        //show error msg
    }
}
4

7 に答える 7

17

No particular problem with this especially if you want to handle the exceptions differently.
However, if the inner exception and the outer exception are of different types E1, E2 respectively and E1 is not a parent of E2, you can have two adjacent catch clauses. 

try
{
  // do something
}
catch (E1 e1)
{
}
catch (E2 e2)
{
}

As noted by Rob and J.Steen - this is slightly different than the case in the question as in this case is E1 is thrown the code after it will not be executed.

于 2012-12-07T08:57:11.817 に答える
2

ネストされた try/catch は問題ありません。避けたいのは、try キャッチに基づいてコードの論理フローを変更することです。つまり、try/catch を if/else ブロックとして扱うべきではありません。したがって、これは理想的ではありません:

//over the top example just to demonstrate my point

public bool IsNumberTen(int x)
{
    try
    {
        if(x > 10)
            throw new NumberTooHighException();
        else if(x < 10)
            throw new NumberTooLowException();
        else
            return true;

    }
    catch(NumberTooHighException)
    {
        return false;
    }
    catch(NumberTooLowException)
    {
        return false;
    }
}
于 2012-12-07T08:58:25.160 に答える
1

This item suggests that its not a bad thing and that you would only have to handle the error in another way any way.

Exception handling try catch inside catch

于 2012-12-07T08:56:35.407 に答える
1

理由がわかりません。失敗するか、処理が必要な例外を発生させる可能性のあるキャッチにロジックがある場合、それは理にかなっています。

于 2012-12-07T08:57:34.860 に答える
0

Its a little difficult to answer this question without knowing what logic is in here. Certainly in terms of performance, nested exception handling will incur a greater cost, but general rule of thumb is only catch exceptions that you as a developer understand how to handle. This overlaps into the practice of TDD where if you have a good enough set of tests you can identify where the expected exceptions should be, then this will dictate your exception logic.

于 2012-12-07T08:57:16.773 に答える
0

私はこれを言うでしょう：それは悪くありません。それが良いかどうかはプログラムに依存し、そのような概念がメソッドのロジックとコントラクトを考慮して意味があるかどうかに依存します。

編集:例外コスト: When to throw and when not toの記事をチェックすることをお勧めします。CLR での例外管理に最もコストがかかるものについて概説します。

于 2012-12-07T08:57:20.250 に答える
0

ネストされたブロックが必要になる可能性がある状況を考えようとしています...おそらく、データベースの変更を行っていて、try catch を仮想トランザクションとして使用している場合、いくつかのプロパティを更新しようとするかもしれませんが、これは失敗しますが、データベースの更新自体を実際にコミットすると、全体的な例外もキャッチされます。

これを考慮しても、これを行う必要はありません...次のように単純にブロックを隣り合わせに積み重ねるだけで十分です。

void MyFun()
{
    try
    {
        //Process logic 1
        // ......
    } catch (Exception ex)
    {
        //show error msg
    }
    try
    {
        //Process logic 2
        // ......
    } catch (Exception ex)
    {
        //write an error details in database
    }

}

また、try catch ブロックをネストする必要がある場合は、コードを設計するためのより良い方法があることにも注意してください。

編集: Itay の答えも入れ子よりもいくらか優れていますが、例外をキャッチすると、ブロック内で続行することはできません。

お役に立てれば！

于 2012-12-07T09:00:36.897 に答える