在VS 2010中Try/Catch未捕获异常
本文关键字:Catch 捕获异常 Try VS 2010 | 更新日期: 2023-09-27 17:59:31
我在VS2010 C#中遇到了一个非常奇怪的事件。我使用的是一个通过netTcpBinding进行回调的WCF PubSub框架。奇怪的是,在我的大型解决方案中的一个代码块中,抛出了一个异常(我完全期待并正在为此进行编码),但调试器停止显示抛出的异常,就好像没有尝试或捕获一样。现在,当我在VS外部仅作为.exe运行应用程序时,程序不会崩溃,并且会相应地处理异常。更奇怪的是,当我在一个新的空白解决方案中创建该应用程序的轻量级版本时,在调试模式下,异常会在VS中被捕获,但当我再次将同一个轻量级项目添加到原始大型项目中时,异常不会被捕获。这是代码块,尽管我认为问题与此解决方案的VS中的设置有关,但这是我唯一的猜测。
基本上,当客户端意外关闭,并且服务试图发送到出现故障的客户端/订阅者时,catch将处理此问题,并将订阅者从列表中删除。订阅者列表是静态只读列表(_S)。我尝试过使服务成为singleton,而不在列表中使用静态关键字,但这似乎没有什么区别。由于明显的原因,我无法压缩并发布它所在的整个解决方案。
public void UpdateData(Action<T> action)
{
_subscribers.ForEach(subscriber =>
{
var client = subscriber as ICommunicationObject;
try
{
if (client != null && client.State == CommunicationState.Opened)
action(subscriber);
else
Unsubscribe(subscriber);
}
catch
{
Unsubscribe(subscriber);
}
}
);
}
我会查看您的Exceptions
设置。我会考虑用以下更干净的逻辑替换:
try
{
if (client != null && client.State == CommunicationState.Opened)
action(subscriber);
}
finally
{
Unsubscribe(subscriber);
}
Heinzi上面的回答解决了这个问题,可以在这里解决:
http://stevesmithblog.com/blog/visual-studio-break-when-exception-thrown/
Heinzi答案的链接已失效,但已存档于此处:
https://web.archive.org/web/20120126024551/http://stevesmithblog.com/blog/visual-引发异常/时工作室中断
这是一份文本。顺便说一句,这对我没有帮助。。。
当异常引发时Visual Studio中断
默认情况下,只有在用户代码中未处理异常时,Visual Studio才会中断。这通常与实际异常发生的地方有一定距离,因为有几个人试图。。。在异常未得到处理之前,catch块可能已经在此期间被涉及。ALT.NET邮件列表上最近的一个线程讨论了一些技巧,如果开发人员真的想看到失败的代码行,可以绕过这个问题。其中一种技术(JonDavis)使用预编译指令来有条件地添加try-catch语句,如下所示:
void MyMethod()
{
#if !DEBUG
try
{
#endif
// the logic that might throw
DoSomething();
#if !DEBUG
}
catch (Exception e)
{
LogError(e);
// etc…
}
#endif
}
这很快就变得很难看,但它完成了任务。然而,另一位列表成员(Nick Blumhardt)在信中指出了Visual Studio的一个功能,如果它是所需的行为,它可以有效地为您做到这一点。从"调试"菜单中,选择"异常"(或使用Ctrl-Alt-E),将显示以下对话框:
图像
如果选中"引发公共语言运行时异常"下的复选框,调试器将在发生错误的行中断,而不是在某个捕获块中未处理错误时中断。使用此选项的缺点是它适用于所有代码,而不仅仅是一个特定的方法。如果你只想在抛出异常时破坏某些代码块,你可以混合和匹配这两种技术,但就我个人而言,我会避免使用前一种技术,因为我认为它会导致更丑陋的代码,不那么清晰,在开发中的行为与生产中的不一样。
还值得指出的是,Visual Basic可以使用Catch Exception When{expression}非常容易地实现这一点。例如,DEBUG标志可以用于When条件。这仍然会导致代码在DEBUG和生产之间的行为有所不同,但至少它要优雅得多,更容易阅读和维护。不幸的是,C#缺少这样一个特性。