在 .NET 中,方法签名不会告诉我是否错过了处理一些可能由我的代码引发的异常。如果说我正在使用 HashTable 删除但尚未处理 ArgumentNullException,是否有一些工具可以警告我?我不想在运行时感到惊讶。
这是否意味着您需要非常了解您的代码,否则未经检查的异常可能更难处理?
在 .NET 中,方法签名不会告诉我是否错过了处理一些可能由我的代码引发的异常。如果说我正在使用 HashTable 删除但尚未处理 ArgumentNullException,是否有一些工具可以警告我?我不想在运行时感到惊讶。
这是否意味着您需要非常了解您的代码,否则未经检查的异常可能更难处理?
实际上,通过终止程序来处理意外异常是处理这种情况的最佳方法,因为通常情况下,当意外发生时,程序状态是未定义的。如果您记录所有异常,并且有一套不错的验收测试,您可以消除由于程序流程导致的意外异常而产生的问题。
通过检查方法输入、类的单元测试和理解你的框架来进行防御性编程将使大多数例外情况发生。
对于 Windows 应用程序:
AppDomain currentDomain = default(AppDomain);
currentDomain = AppDomain.CurrentDomain;
// Handler for unhandled exceptions.
currentDomain.UnhandledException += UnhandledExceptionHandler;
// Handler for exceptions in threads behind forms.
Application.ThreadException += ThreadExceptionHandler;
public static void UnhandledExceptionHandler(object sender, UnhandledExceptionEventArgs e)
{
}
public static void ThreadExceptionHandler(object sender, Threading.ThreadExceptionEventArgs e)
{
}
您尝试完成的工作没有语言支持。我们为 VS 编写了一个自定义插件,以确保我们 API 的所有入口点都有用于日志记录的尝试捕获。但是,我从来没有看到强制你覆盖所有可能声明的异常情况的语言的价值,因为你仍然需要编写一些代码来对错误做一些有意义的事情。大多数人只是查看编译器抱怨编写处理程序并在一些无用代码中隐藏可能有用的错误。在某些情况下,最好是失败并知道存在问题。
您应该为您的应用程序添加最高级别的异常处理程序,并为您的应用程序编写单元、功能和集成测试,这将测试所有可能的用例。这将帮助您消除几乎所有未经检查的异常。
也尽量不要捕获异常,而是消除原因。(即不抓ArgumentNullException
但不通过null