如果我们只想记录异常，是否应该将 try catch 与函数一起使用？答案

【问题标题】：Should we put try catch with function if we just want to log the exception?如果我们只想记录异常，是否应该将 try catch 与函数一起使用？
【发布时间】：2017-08-27 18:05:43
【问题描述】：

在asp.net应用程序中，所有发生且不在try catch中的异常都可以由application_error处理。

如果我们只需要记录异常及其堆栈跟踪，并且不需要在 catch 内部做出任何其他决策/逻辑，为什么要将 try catch 放在 application/bl 或 dal 层函数中？是否有任何理由将 try/catch 与每个数据库调用函数一起使用？

例如，我们在 DAL 层中有数百个函数执行以下代码：

try
{
  //open db connection, execute stored procedure
}
catch
{
  //log error
}

如果我们从存储过程或打开数据库连接中得到任何异常，我们会得到一个异常，但除了记录这些错误之外，我们没有做任何事情。我们没有非常关键的数据存储/检索要求。我们正在记录错误只是为了得到警报并稍后修复它。在每个这样的函数中加入 catch 是否正确？

【问题讨论】：

无论如何使用try 和catch 都是有原因的。这只是编程的基本部分。所以，答案是肯定的。
那是什么原因？特别是通过将日志记录异常放在 application_error 函数中我们无法实现的目标？
不要让您的代码回退到 application_error。每个错误都应该在它产生的范围内处理。 application_error 是你最后的后备，理论上不应该达到。
我得到了理论部分。但这背后的原因是什么？如果我把东西放在 application_error 中，我看到了不使用多个函数的 try catch 的好处。我想了解将其作为功能级别的好处？
异常意味着有些事情没有完成。如果某些事情没有完成，您的业务流程就会失败。如果您的业务流程失败，您需要了解它并在该代码范围内处理它，而不是在 application_error 中。

标签： c# asp.net exception exception-handling

【解决方案1】：

使用try 和catch 不仅仅用于记录目的，尤其是在处理数据库连接时。

异常意味着某事未完成。如果某些事情没有完成，您的业务流程就会失败。如果您的业务流程失败，您需要了解它并在该代码范围内处理它，而不是application_error。每个错误都应该在它产生的范围内处理。 application_error 应该是你最后的后备，理论上不应该达到。

当然，您可以使用它进行日志记录，也可以用于关闭数据库连接（可能在异常发生之前打开并永远保持打开状态），通知您的用户发生了异常，以及用于数据恢复，交替您的处理异常或准备重试的过程。

因此，使用您发布的模板，良好的代码处理应该如下所示：

try
{
  //open db connection, execute stored procedure
}
catch
{
    // Inform the user
    // Alternate your process or preparing for retry
    // log error
}
finally
{
    // Close the DB connection
}

【讨论】：

如果我们使用 dapper，可以自动处理关闭数据库连接。 (stackoverflow.com/questions/40824948/…)。如果我们没有任何要求重试相同的请求，日志部分不应该在某个通用级别处理吗？
@maverick 这是基于意见的，但在我看来，使用“一般”错误处理，如您所说的“通用级别”，是不好的做法。再一次 - 每个错误都有一个含义，没有一般错误这样的东西。每个失败的数据库执行都有其后果，应在其范围内加以处理。

【解决方案2】：

应该只在可以有意义地处理异常的地方使用 try/catch 块。然而，“有意义的处理”包括提供良好的错误信息。

如果您的 catch 块只是简单地记录了没有额外上下文的异常，那么可以用执行相同操作的顶级处理程序（如 application_error）替换此类块。

但是，如果您记录仅在调用时可用的其他信息，那么使用 catch 块是完全合理的：它通过提供更好的诊断来增强体验，这是一个完全合理的目标。

【讨论】：