1

ロギングをスキップして再スローするために、例外がより高いアプリケーションレベルで処理されているかどうかを確認する方法はありますか? たとえば、次のようにします。

        try
        {
            // Execute some code
        }
        catch (Exception e)
        {
            if(!ExceptionIsHandled())
                LogError(e);
            throw e;
        }
4

4 に答える 4

1

私が知っていることは何もありません。この設計にコミットしている場合 (末尾の注を参照)、ある種の Exception のラッパーを作成し、それをスローされるものにすることができます。次に、コードを次のようにすることができます。HandledExceptionInnerException

    try
    {
        // Execute some code
    }
    catch (HandledException e)
    {
        LogError(e.InnerException);
        // Do something else
    }
    catch (Exception e)
    {
        throw ;
    }

これが典型的なStackoverflowの「あなたは間違っている」という答えの部分です...

ただし、例外を本当に「処理」した場合は、例外を再スローしてもあまり意味がありません。おそらく、あなたのメソッドは失敗した結果を返すだけでException、何がうまくいかなかったのかの詳細項目として を含むはずです。

于 2013-02-04T22:52:09.400 に答える
0

いいえ、まだそこにありません。例外はハンドラーを介して発生します。これについて行く通常の方法。独自の例外を定義し、現在の場所で処理しようとしている例外のみをキャッチします。

于 2013-02-04T22:57:27.387 に答える
0

例外フィルターをサポートする言語で記述された、特別に設計された try-catch ブロック内にコードがラップされていることが確実である場合、スタックの巻き戻し前または巻き戻し中に、例外がそれによってキャッチされる可能性が高いかどうかを判断できます。外側のブロックまたは内側のブロックによって。ただし、これの有用性はかなり制限されています。特に、例外が発生したことを確認する目的で、解決されないことがわかっている例外をキャッチして再スローするコードの非常に一般的なアンチパターンを考えると、.

単に冗長なロギングを回避することが目標である場合は、冗長性を効率的に処理できるロギング機能を使用することをお勧めします。外側の層で例外を 1 回だけログに記録する方がよいと主張する人もいるかもしれませんが、より多くのログ記録の機会を持つことには利点があります。内側の層で例外が発生し、中間層がそれを飲み込んだ場合、外側の層内のコードをログに記録しても、それが検出されることはありません。対照的に、内側のレイヤーが例外をキャプチャしてログに記録するように手配することから始めた場合、中間レイヤーが例外を飲み込んだとしても、例外が発生したという事実は記録される可能性があります。

于 2013-02-05T22:21:09.277 に答える