没有什么比在调试器中看到您的代码在一个异常的方法上崩溃并且您没有尝试/捕获它更令人沮丧的了。
是否有一种简单的方法可以扫描您的源代码并标记所有可能引发异常的函数?
内置视觉辅助是否有一些隐藏的选项可以用特定颜色为这些功能着色?
谢谢
R
除了最琐碎的代码外,所有代码都可能引发异常(至少内存不足)。您最好防御性地编写代码,至少使用全局 try/catch,而不是尝试微观管理哪些代码段将或不会引发异常。
不,没有办法自动执行此操作,也没有一种好方法可以获取方法引发的所有可能异常的列表。这里有几个原因
我认为 redgate 为这个“异常猎人”提供了一些工具,他们在试用后收费。
正如其他人所说,我不确定您是否会在 C# 中找到一种万无一失的方法,因为它不支持检查异常。
顺便说一句,这让我想起了 Anders Hejlsberg 的一次采访,讨论“检查异常的麻烦”。我并不是要激怒检查的异常,而是建议您阅读 Ander 的 C# 异常设计背后的基本原理以及处理异常的建议方法:集中式异常处理。
我认为 resharper 会为您提供有关异常的提示。但是由于 C# 不支持检查异常的原因,有办法确定异常。也许像 NDepend 之类的代码分析工具支持这一点。
一切都可以抛出异常。查看 MSDN 以获取方法可以抛出的异常列表。
所有非空方法都可以以一种或另一种形式抛出异常。如果您担心自己生成的异常,您可以从智能感知中显示它们,就像框架方法通过 XML 文档一样,如下所示:
/// <summary>
/// I seem to have written a method to do a thing.
/// </summary>
/// <exception cref="System.Exception">An unfortunate failure.</exception>
public void DoSomething()
{
/* ... */
}
任何代码都可能导致异常,您的工作是尝试并预测这一点!
有许多第三方工具可以帮助查找一些常见错误,例如 fxcop 和重构等工具可以提出建议。
目前已经完成了一些工作,可以帮助您找到潜在的异常。查看 PEX,它可以帮助为您的函数生成测试:research.microsoft.com/en-us/projects/Pex/(链接在发布时似乎已关闭)
另一个令人兴奋的领域是代码合同(在 .net 4 中/作为规范#提供)。代码契约允许您编写指定必须满足的条件的语句。这些可以在你的函数被调用之前和之后,你也可以声明不变量。条件可能像 value != null 这样简单。然后在编译和运行时分析这些条件,以检查没有代码路径违反它们。
正如其他人所说,您应该假设每一行代码都可以引发异常,除非您已经证明它不能。更好的问题是,“你打算怎么做?”
通常,您根本不应该捕获任何异常。
当然,其他一切都是该规则的例外。捕获异常以便记录它是有意义的(如果您的环境不为您这样做,就像 ASP.NET 那样)。捕获异常以将其替换为提供有关上下文的更多详细信息的另一个异常是有意义的:
public int GetConfiguredInteger(string name) {
string s = null;
try {
s = GetStringFromConfigFile(name);
}
catch (IOException ex) {
throw new Exception(String.Format(
"Error in configuration file foo.config when processing {0}", name),
ex);
}
return int.Parse(s);
}
如果您没有告诉调用者,调用者不可能知道 IOException 是由配置文件引起的。还要注意我如何忽略与文件 I/O 无关的所有异常。特别要注意 int.Parse 甚至不在 try/catch 块内。
还有少量其他此类异常,但捕获异常的基本思想是:除非不这样做会更糟,否则不要这样做。
异常查找器中有一个反射器添加 ,它将显示方法可能引发的异常。我没有使用它,但在 .Net 用户组会议上看到了它的一个示例。
有一个工具可以做到这一点。您可以下载试用版,看看您是否喜欢它。我真的不认为这有必要,但如果你在一家公司工作并且他们会为此付出代价,你可能想要调查一下。就像之前所说的那样,有太多可能的例外被提出。查看Excpetion Hunter
我发现打破外部 catch 块并挖掘到异常发生的实际点更令人沮丧。
大多数情况下,如果抛出异常并且我没有预料到它,我发现了一个错误,如果它没有被一些无所事事的异常处理混淆,那么解决它会更容易。
编辑: 由于您的示例实际上是一个很好的示例,因此我仍然不相信这样的工具会对您有所帮助。会有很多可能的异常,实际上每一行代码都可能抛出,你很难找到“有趣”的异常。
少数人提到的 Exception Hunter 是一个很好的工具来帮助解决这个问题。我不知道它是否与<exception>
XML-Doc 注释有关联,以便您可以强制记录代码引发的异常。