无法捕获的异常,第 2 部分
更新:我已在 Microsoft Connect 上提交了错误报告:https://connect.microsoft.com/VisualStudio/feedback/details/568271/debugger-halting-on-exception- thrown-inside-methodinfo-invoke #details
如果您可以在您的计算机上重现此问题,请投票支持该错误,以便修复它!
好的,我已经做了一些测试,并将问题简化为非常简单的事情:
i。在新类中创建一个抛出异常的方法
public class Class1 {
public void CallMe() {
string blah = null;
blah.ToLower();
}
}
:创建一个指向其他地方的该方法的 MethodInfo
Type class1 = typeof( Class1 );
Class1 obj = new Class1();
MethodInfo method = class1.GetMethod( "CallMe" );
:将对 Invoke() 的调用包装在 try/catch 块中:
try {
method.Invoke( obj, null ); // exception is not being caught!
} catch {
}
iv.在没有调试器的情况下运行程序(工作正常)。
v. 现在使用调试器运行程序。当异常发生时,调试器将停止程序,即使它被包装在试图忽略它的 catch 处理程序中。 (即使您在 catch 块中放置一个断点,它也会在到达断点之前停止!)
事实上,当您在没有调试器的情况下运行它时,也会发生异常。在一个简单的测试项目中,它会在其他级别被忽略,但如果您的应用程序具有任何类型的全局异常处理,它也会在那里被触发。 [参见评论]
这是这让我非常头疼,因为它不断触发我的应用程序的崩溃处理程序,更不用说尝试调试的痛苦了。
Update: I've filed a bug report on Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/details/568271/debugger-halting-on-exception-thrown-inside-methodinfo-invoke#details
If you can reproduce this problem on your machine, please upvote the bug so it can be fixed!
Ok I've done some testing and I've reduced the problem to something very simple:
i. Create a method in a new class that throws an exception:
public class Class1 {
public void CallMe() {
string blah = null;
blah.ToLower();
}
}
ii. Create a MethodInfo that points to this method somewhere else:
Type class1 = typeof( Class1 );
Class1 obj = new Class1();
MethodInfo method = class1.GetMethod( "CallMe" );
iii. Wrap a call to Invoke() in a try/catch block:
try {
method.Invoke( obj, null ); // exception is not being caught!
} catch {
}
iv. Run the program without the debugger (works fine).
v. Now run the program with the debugger. The debugger will halt the program when the exception occurs, even though it's wrapped in a catch handler that tries to ignore it. (Even if you put a breakpoint in the catch block it will halt before it reaches it!)
In fact, the exception is happening when you run it without the debugger too. In a simple test project it's getting ignored at some other level, but if your app has any kind of global exception handling, it will get triggered there as well. [see comments]
This is causing me a real headache because it keeps triggering my app's crash-handler, not to mention the pain it is to attempt to debug.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我可以在我的 .NET 4 机器上重现这一点,你是对的 - 它只发生在 .NET 4.0 上。
对我来说,这很像一个错误,应该继续在 MS Connect 上进行。如果这使您的崩溃处理程序绊倒,则严重令人沮丧。听起来解决此问题的一种不太令人满意的方法是将调用的方法包装在其自己的处理程序中。 :-(
不过,我无法重现的一件事是触发崩溃处理程序。这是我的程序:
I can reproduce this on my .NET 4 box, and you're right -- it only happens on .NET 4.0.
This smells very much like a bug to me, and should go on MS Connect. Major bummer if this is tripping your crash handler. Sounds like a non-pleasing way to work around this is to wrap the invoked method inside its own handler. :-(
One thing I can not reproduce, though, is tripping the crash handler. Here's my program:
您无法捕获所有异常。您的示例中有一些假设。例如,您假设异常是在调用线程上引发的。捕获其他线程上未处理的异常取决于您使用的运行时(控制台、winforms、WPF、ASP.Net 等)。
此外,对 System.Environment.FailFast() 的调用不会生成任何可处理的条件 - 进程被有效终止,没有机会进行干预。
You can't catch all exceptions. There's a few assumptions in your example. You are, for instance, assuming the exception was raised on the calling thread. Catching unhandled exceptions on other threads depends on which runtimes you're using (console, winforms, WPF, ASP.Net, etc).
Additionally, calls to System.Environment.FailFast() do not generate any handlable condition - the process is effectively terminated with no chance for intervention.