6

次のようなコードについてどう思いますか。

public void doSomething()
{
    try
    {
       // actual code goes here
    }
    catch (Exception ex)
    {
        throw;
    }
}

私が見る問題は、実際のエラーが処理されず、例外が別の場所にスローされることです。実際の問題がある行番号を取得できないため、デバッグがより困難になります。

だから私の質問は、なぜこれが良いのでしょうか?

- - 編集 - -

答えからすると、ほとんどの人は、カスタムや特定の例外をキャッチせずにこれを行うのは無意味だと言っているようです。それは、特定の例外がキャッチされていないときに、私がコメントしたかったことです。このコードのやり方ではなく、キャッチされた例外で実際に何かを行うポイントがわかります。

4

10 に答える 10

16

見ている品質によっては、別の場所で例外をスローしていません。ターゲットなしで「スロー」すると、例外のスローとは大きく異なる例外が再スローされます。主に、再スローはスタック トレースをリセットしません。

この特定のサンプルでは、​​catch は何もしないので意味がありません。例外は問題なく再スローされ、まるで try/catch が存在しなかったかのようです。

于 2009-04-15T13:45:01.933 に答える
3

理想的には、catch ブロックが何らかの処理を行ってから再スローします。たとえば、

try
{
    //do something
}
catch (Exception ex)
{
    DoSomething(ex); //handle the exception
    throw;
}

もちろん、コードの上位層でさらに処理を行いたい場合は、再スローが役立ちます。

于 2009-04-15T13:48:44.450 に答える
1

そのようなことをすることはかなり無意味であり、一般的に私は無意味なことをする道をたどらないようにしています;)

ほとんどの場合、処理方法を知っている特定の種類の例外をキャッチすることをお勧めします。たとえそれが、より多くの情報を使用して独自の例外を作成し、キャッチした例外を InnerException として使用することを意味するだけであってもです。

于 2009-04-15T13:46:52.067 に答える
1

コール スタックの上位で例外を処理する場合など、これが適切な場合もあります。ただし、意味をなすために再スローする以外に、catch ブロックで何かを行う必要があります。たとえば、エラーをログに記録します。

public void doSomething()
{
    try
    {
       // actual code goes here
    }
    catch (Exception ex)
    {
        LogException (ex);  // Log error...
        throw;
    }
}
于 2009-04-15T13:48:55.683 に答える
0

一般的な例外がこのようにキャッチされ、カスタム例外オブジェクトに再パックされるインスタンスを見てきました。

それとあなたが言っていることの違いは、これらのカスタム Exception オブジェクトは、実際に発生した例外に関する情報を保持することであり、それ以下ではないということです。

于 2009-04-15T13:44:09.673 に答える
0

手始めに、私は単にやります

catch
{
   throw;
}

ただし、基本的に、複数のタイプの例外をトラップする場合は、一部をローカルで処理し、残りをスタックにバックアップすることをお勧めします。

例えば

catch(SQLException sex) //haha
{
   DoStuff(sex);
}
catch
{
   throw;
}
于 2009-04-15T13:46:27.420 に答える
0

「このように見える」という意味に依存し、キャッチブロックに他に何もない場合は再スローします...その場合、あなたが言うように、例外が発生した場所を難読化することを除いて、try catchは無意味です. ただし、エラーが発生した場所で何かを行う必要があるが、スタックのさらに上で例外を処理したい場合は、これが適切な場合があります。ただし、キャッチは、例外ではなく、処理している特定の例外に対するものになります。

于 2009-04-15T13:47:28.183 に答える