Question

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

如果我们只需要记录异常及其堆栈跟踪，并且我们不需要在catch中进行任何其他决策/逻辑，为什么我们应该在application / bl或dal层函数中放置try catch？有没有理由把try / catch放到每个数据库调用函数中？

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

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

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

Answer 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
}

Answer 2

只应在可以有意义地处理异常的地方使用try / catch块。然而，＆＃34;有意义的处理＆＃34;包括提供良好的错误消息。

如果你的catch块只是简单地记录了没有附加上下文的异常，那么这个块可以替换为执行相同操作的顶级处理程序（如application_error）。

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

如果我们只想记录异常，我们应该把try catch与函数放在一起吗？

2 个答案: