Question

我已经完成了创建常规异常处理代码段的任务，我有几个问题：

这是一个好主意吗？一般的异常处理会导致关于什么破坏的广义消息，使跟踪变得困难。导致：

我应该在代码段中包含哪些内容？我觉得此处更少，但添加日志似乎是一个好主意，因为我不认为异常消息会非常具体。

Answer 1

我不会说这是个好主意，不。我的代码中往往只有相对较少的异常处理程序。他们通常在那里：

偶尔会将一种类型的异常转换为另一种类型的异常（尽管在C＃中比在Java中更罕见;它是否是一件好事是一个不同的讨论）
在特定请求/用户操作/其他任何内容的堆栈根目录中捕获错误，通常只记录结果
处理在非特殊情况下抛出异常的骨头API

这些都不需要花很长时间才能完成，并且没有一个经常出现，因此值得拥有一个共同的片段。

有一组围绕异常处理的文档化约定 - 在同一文档中讨论设计 - 是一个好主意。

Answer 2

最好添加特定的异常处理并包括日志......但是，您也可以添加常规异常，以捕获所有未知异常。

Answer 3

堆栈跟踪（对于那些可以读取它们的人）是你需要的90％。包括传递给错误方法的参数也将极大地帮助调试。如果这是记录到数据库，请注意记录敏感的数据（PII或PHI）。

如果这是一个Web应用程序，我建议同时保存会话的快照，这也有助于调试。

Answer 4

我建议您使用Code Contracts和PostSharp等AOP工具。它们都为调试和错误处理代码提供了很好的可能性。

Answer 5

我总是使用these guidelines作为异常处理的内容，不应该处理什么。此外，get exceptions right很难我通常最终得到的代码是几乎没有特定异常处理程序的代码，以及一个只记录异常（包括堆栈跟踪）的全局catch-all处理程序。

那就是说，当你使用本地异常处理时，如果缺少默认的try.snippet，这样的东西可能会起作用（只包含代码，其余的.snippet文件有点明显）：

try 
{           
  $selected$
}
catch ($caughtExceptionType$Exception ex)
{
  $end$
  Logger.Error("$message", ex);
  //throw new $customExceptionType$Exception("$message", ex);
}

Answer 6

我认为一般的异常处理程序策略仅适用于您希望处理未处理的异常的代码中的入口点。可能在Main方法中用于单线程应用程序代码或AppDomain.UnhandledException事件。

然后，使用的策略是高度应用程序特定的。也许您有一个中央日志来添加信息，或者一个消息队列将触发进一步处理（例如，插入数据库并通知管理员）。

异常处理程序代码片段

6 个答案: