n 层应用程序中的异常处理？

Question

在分层应用程序中处理异常的建议方法或最佳实践是什么？

• 您应该在哪里放置 try/catch 块？
• 您应该在哪里实施日志记录？
• 是否有建议的模式用于管理 n 层应用程序中的异常？

考虑一个简单的例子。假设您有一个 UI，它调用业务层、调用数据层：

//UI
protected void ButtonClick_GetObject(object sender, EventArgs e) 
{
    try {
        MyObj obj = Business.GetObj();
    }
    catch (Exception ex) {
        Logger.Log(ex); //should the logging happen here, or at source?
        MessageBox.Show("An error occurred");
    }
}

//Business
public MyObj GetObj()
{
    //is this try/catch block redundant?  
    try {
        MyObj obj = DAL.GetObj();
    }
    catch (Exception ex) {
        throw new Exception("A DAL Exception occurred", ex);
    }
}

//DAL
public MyObj GetObj()
{
    //Or is this try/catch block redundant? 
    try {
        //connect to database, get object
    }
    catch (SqlException ex) {
        throw new Exception("A SQLException occurred", ex);
    }
}

您对上述异常处理有何批评？

谢谢

Answer 1

我的经验法则通常是在顶层捕获异常并在那里记录（或以其他方式报告）它们，因为这是您拥有有关错误的最多信息的地方 - 最重要的是完整的堆栈跟踪。

然而，可能有一些原因需要在其他层捕获异常：

1. 异常已实际处理。连接失败，但层会重试。
2. 重新抛出异常并提供更多信息（通过查看堆栈尚无法获得这些信息）。例如。 DAL 可能会报告它正在尝试连接到哪个数据库，而 SqlException 不会告诉您。
3. 异常被转换为更通用的异常，它是该层接口的一部分，并且可能（或可能不）被更高层处理。例如。 DAL 可能会捕获连接错误并抛出DatabaseUnavailableException。对于不重要的操作，BL 可能会忽略这一点，或者对于那些不重要的操作，BL 可能会让它传播。相反，如果 BL 捕获了 SqlException，它将暴露于 DAL 的实现细节。相反，抛出DatabaseUnavailableException 的可能性是DAL 接口的一部分。

在多个层记录相同的错误通常没有用，但我可以想到一个例外：当较低层不知道问题是否严重时，它可以将其记录为警告。如果更高层认为它很重要，那么它可以将相同的问题记录为错误。

Answer 2

以下是我遵循的与异常处理相关的一些规则：

• 异常应该只在可以实现处理它们的逻辑的层中捕获。大多数情况下，这种情况发生在最上层。根据经验，在层内实现 catch 之前，问问自己任何上层的逻辑是否以任何方式依赖于异常的存在。例如，在业务层中，您可能有以下规则：如果外部服务可用，则从外部服务加载数据，如果不可用，则从本地缓存加载数据。如果调用服务抛出一个错误，您可以在 BL 级别捕获并记录它，然后从缓存中返回数据。在这种情况下，上层 UI 层不必采取任何操作。但是，如果服务和缓存调用都失败，则异常必须转到 UI 级别，以便可以向用户显示错误消息。
• 应用程序内的所有异常都应该被捕获，如果没有特殊的逻辑来处理它们，那么至少应该记录它们。当然，这并不意味着您必须将所有方法的代码包装在 try/catch 块中。相反，任何应用程序类型都有一个用于未捕获异常的全局处理程序。例如，在 Windows 应用程序中，应实现 Application.ThreadException 事件。在 ASP .Net 应用程序中，应实现 global.asax 中的 Application_Error 事件处理程序。这些位置是您可以在代码中捕获异常的最上面的位置。在许多应用程序中，这将是您捕获大多数异常的地方，除了日志记录之外，您还可能在这里实现一个通用且友好的错误消息窗口，该窗口将呈现给用户。
• 您可以在需要的地方实现 try/finally 功能，而无需实现 catch 块。如果不需要实现任何异常处理逻辑，则不应实现 catch 块。例如：

SqlConnection conn = null;  
try
{
    conn = new SqlConnection(connString);
    ...
}
// do not implement any catch in here. db exceptions logic should be implemented at upper levels
finally
{
    // finalization code that should always be executed.
    if(conn != null) conn.Dispose();
}

• 如果您需要从 catch 块重新抛出异常，只需使用 throw; 即可。这将确保保留堆栈跟踪。使用 throw ex; 将重置堆栈跟踪。
• 如果需要使用对上层更有意义的另一种类型重新抛出异常，请将原始异常包含在新创建的异常的 InnerException 属性中。
• 如果您需要从代码中抛出异常，请使用有意义的异常类型。

Answer 3

首先要解决的问题是永远不要抛出一般异常。

第二，除非确实有充分的理由包装异常，否则只需在 catch 子句中使用 throw; 而不是 throw new... 。

第三（这不是一个硬性规定），不要在 UI 层以下的任何点捕获一般异常。 UI 层应该捕获一般异常，以便可以向最终用户显示用户友好的消息，而不是发生爆炸的技术细节。如果您在更深的层中捕获一般异常，则它可能会无意中被吞没，并导致很难追踪的错误。

Answer 4

异常处理在任何应用程序中都是困难的。您需要考虑每一个例外情况，并快速形成适合您的模式。我尝试将异常分为以下类别之一...

• 只有在您的代码错误（或者您不理解，或者您无法控制它们）时才应该发生的异常：

示例：也许您的持久性框架要求您捕获可能由格式错误的 SQL 引起的 SQL 异常，但是，您正在执行硬编码的查询。

处理：根据我的经验，大多数异常都属于这一类。至少，记录它们。更好的是，将它们发送到记录它们的异常处理服务。然后，将来如果您决定要以不同的方式记录它们或对它们执行不同的操作，您可以在一处进行更改。也许您还想向 UI 层发送一个标志，表明发生了某种错误，他们应该重试操作。也许您给管理员发了邮件。

您还需要向更高层返回一些内容，以便服务器上的生命继续进行。也许这是一个默认值，或者也许这是空。也许您有某种方法可以取消整个操作。

另一种选择是为异常处理服务提供两种处理方法。 handleUnexpectedException() 方法会通知用户，但不会重新抛出异常，如果您能够自行展开堆栈或以某种方式继续，则可以返回默认值。 handleFatalException() 方法会通知用户并重新抛出某种异常，以便您可以让抛出的异常为您展开堆栈。

• 实际由用户引起的异常：

示例： 用户尝试更新 foobar 小部件并为其指定新名称，但具有该名称的 foobar 小部件已存在他们想要。

处理：在这种情况下，您需要将异常返回给用户。在这种情况下，您可以继续抛出异常（或者更好，甚至不捕获它），直到它到达 UI 层，然后 UI 层应该知道如何处理异常。确保记录这些异常，以便您（或编写 UI 的任何人）知道它们的存在并知道它们的存在。

• 您实际可以处理的异常：

示例：您进行远程服务调用，远程服务超时，但您知道他们有这样做的历史记录，您应该重做的电话。

处理：有时，这些异常从第一类开始。当你的应用程序运行了一段时间后，你意识到你实际上有一个很好的方法来处理它。有时，例如乐观锁定的异常或中断的异常，捕获异常并对其执行某些操作只是业务的一部分。在这些情况下，处理异常。如果你的语言（我认为是 Java）区分受检查和非受检查的异常，我建议这些异常始终是受检查的。

为了解决您的上述问题，我会将初始异常委托给一个服务，该服务会通知用户，并且根据 MyObj 是什么类型的对象（例如设置），我可能会让这是一个非致命异常并返回默认值，或者如果我不能这样做（例如用户帐户），那么我可能会让这是一个致命的异常，所以我不必担心它。

Answer 5

我为每一层使用单独的异常类（DALException，BLException，...）来记录（例如：在文件中）层边界处的异常（这是针对管理员的），因为用户只应该看到清晰且可理解的错误消息。这些异常应该在由所有数据访问层继承的 DAlBase 上处理，并在所有层上进行此类调用。这样我们就可以将异常处理集中在几个类中，开发人员只会抛出层异常（例如：DALException）
查看更多信息多层异常处理。