C#重新启动异常:如何在IDE中获取异常堆栈? [英] C# rethrow an exception: how to get the exception stack in the IDE?

查看:99
本文介绍了C#重新启动异常:如何在IDE中获取异常堆栈?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

以前有关于推翻异常的正确方法的讨论。相反,这个问题是关于如何在使用rethrow时从Visual Studio获取有用的行为。



考虑这个代码:

  static void foo(){
throw new Exception(boo!);
}

static void Main(string [] args){
try {
foo();
} catch(异常x){
//做一些东西
throw;
}
}

出现的异常具有正确的堆栈跟踪,显示foo()作为异常的来源。 但是,GUI调用堆栈窗口只显示Main,而我期望它显示异常的调用堆栈,一直到foo。



当没有重发时,我可以使用GUI快速浏览调用堆栈,看看什么调用导致异常以及我们到达那里。



随着重新抛出我想要做同样的事情。相反,GUI显示的调用堆栈对我来说没有用。我必须将异常详细信息复制到剪贴板,将其粘贴到记事本,然后手动导航到我感兴趣的任何调用堆栈的功能。



由方式,如果我添加 [MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)] 或者如果我将catch更改为 catch,我会得到相同的行为(例外)



我的问题是:鉴于我使用的代码重用,有人可以建议一种方便的方式来浏览调用堆栈与异常相关?我正在使用Visual Studio 2010。

解决方案

调试器在 throw Main 中,因为该异常未被处理。默认情况下,调试器只会打破未处理的异常。一旦您在 Main 中停止,来自 foo 的原始异常的调用堆栈出现在异常中,但是所有的其他上下文已经丢失(例如本地,堆栈/内存状态)。



这听起来像你想让调试器在 foo 中抛出,所以你应该告诉调试器打破第一例异常:


  1. 调试»例外...( Ctrl + Alt + E

  2. 对于您关心的异常类型(在本例中为Commange语言运行时异常),请检查Thrown。

  3. 单击确定

  4. 开始调试

在这种情况下,当 foo throws时,调试器会立即中断一个例外。现在,您可以在原始异常的上下文中检查堆栈,本地人等。如果您继续执行( F5 ),调试器将在 Main 中重新打破。



采取另一种方法,如果您正在运行VS2010 Ultimate,您还可以使用IntelliTrace向后调试,以查看异常时的参数,线程和变量。有关详细信息,请参阅此MSDN文章。 (全面披露:我在与IntelliTrace密切相关的团队工作)。


There has been discussion here before about the correct way to rethrow an exception. This question, instead, is about how to get useful behavior from Visual Studio when using rethrow.

Consider this code:

   static void foo() {
        throw new Exception("boo!");
    }

    static void Main(string[] args) {
        try {
            foo();
        } catch (Exception x) {
            // do some stuff
            throw;
        }
    }

The exception that comes out has the correct stack trace, showing foo() as the source of the exception. However, the GUI Call Stack window only shows Main, whereas I was expecting it to show the exception's call stack, all the way to foo.

When there is no rethrow, I can use the GUI to very quickly navigate the call stack to see what call caused the exception and how we got there.

With the rethrow I'd like to be able to do the same thing. Instead, the call stack that the GUI shows is of no use to me. I have to copy the exception details to the clipboard, paste it to Notepad, and then manually navigate to whichever function of the call stack I'm interested in.

By the way, I get the same behavior if I add [MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)] or if I change the catch to just catch (Exception).

My question is: given that the code I have uses rethrow, can someone suggest a convenient way to navigate the call stack associated with the exception? I'm using Visual Studio 2010.

解决方案

The debugger breaks at the throw in Main because that exception is unhandled. By default, the debugger will only break on unhandled exceptions. Once you've stopped at Main, the call stack for the original exception from foo is present in the exception, but all of the other context has been lost (e.g. locals, stack/memory state).

It sounds like you want the debugger to break on the throw in foo, so you should tell the debugger to break on first-chance exceptions:

  1. Debug » Exceptions... (Ctrl+Alt+E)
  2. Check "Thrown" for the exception types you care about (in this case, Commange Language Runtime Exceptions)
  3. Click OK
  4. Start debugging

In this case, the debugger will break immediately when foo throws an exception. Now, you can examine the stack, locals, etc., in the context of the original exception. If you continue execution (F5), the debugger will break again on the rethrow in Main.

Taking another approach, if you're running VS2010 Ultimate, you can also use IntelliTrace to "debug backwards" to see parameters, threads, and variables at the time of the exception. See this MSDN article for details. (Full disclosure: I work on a team closely related to IntelliTrace).

这篇关于C#重新启动异常:如何在IDE中获取异常堆栈?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆