1

プロダクションコードで（try catchブロックを削除して）簡単にデバッグできるようにする方法として、条件付きコンパイルを使用しています。私がこれを行う理由は、Visual Studioが（明らかに）スローされた例外の場所を最上位のハンドラーのキャッチブロックとして表示するためです。残念ながら、これにより、ハンドラーを削除するまで、デバッグや少なくともエラーの正確な場所の特定ができなくなります。

これが私の現在のアプローチの例です

    private void btnConnect_Click(object sender, EventArgs e)
    {
#if DEBUG
        DoSomething();
#else
        try 
        {
            DoSomething();
        } 
        catch (Exception ex) 
        {
            Logger.Log(ex);
            MessageBox.Show(ex.Message, "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
        }
        finally 
        {
            CleanUp();
        }
#endif
    }

このアプローチはコードの大幅な重複を引き起こし、私は代替案を見つけたいと思っています。

ラムダを使用して、条件付きコンパイルを内部的に使用してこのような例外を処理または再スローするカスタムtrycatchブロックハンドラーを作成するアプローチを検討しました。

    void TryCatchFinally(Action tryBlock, Action<Exception> catchBlock, Action finallyBlock)
    {
#if DEBUG
        tryBlock.Invoke();
        finallyBlock.Invoke();
#else 
        try
        {
            tryBlock.Invoke();
        }
        catch (Exception ex)
        {
            catchBlock.Invoke(ex);
        }
        finally
        {
            finallyBlock.Invoke();
        }
#endif
    }

しかし、私は標準のtry catch構文を維持したいと思います（さらに、このアプローチは、大きな変更なしに既存のコードに適用できないことを意味します）

誰かがこの問題への良いアプローチを見つけましたか、または誰かが私のバージョンの改善を考えることができますか？

4

1 に答える 1

2

なぜこれを行う必要があるのか​​わかりません-誰かがこのようなデバッグ例外に近づくのを見たことがありません。

別のコードパスを必要とせずに、例外がスローされたときに中断するようにVisual Studioを構成できることをご存知ですか？

デバッグ->例外->「スロー」をチェック

質問を正しく理解していれば、VSでのデバッグの問題は解決します。

于 2012-04-23T09:59:23.630 に答える