什么应该是最好的异常处理策略

Question

我正在处理用户从UI调用方法的应用程序,我正在调用一个调用另一个方法的业务类的方法

UI - > Method1 - > Method2 - > Method3

如果在任何方法中发生任何异常,我想向用户显示错误消息.

我应该将异常直接抛到调用方法,在UI层我将捕获异常并显示消息.

除了抛出异常并在调用者处捕获它有没有更好的方法来处理它？

我不想使用C++约定,其中返回整数作为结果.

Answer 1

如果无法从发生异常的方法中的异常中恢复,请不要尝试捕获它(除非您想记录它,在这种情况下,在记录之后再次抛出它).然后赶上UI级别.

试图在每个级别捕获异常只会给代码增加膨胀.

Answer 2

鉴于您的 UI--> Method1 -->Method2 --> Method3 示例，我将确保 UI 有一个 try/catch，但是其他方法都不应该捕获异常，除非它们可以在不重新抛出的情况下处理它们。即使他们处理了异常，您也应该首先质疑该异常是否应该发生。如果您处理异常并继续您的快乐方式，那么该异常就是您正常流程的一部分，这是一种严重的代码味道。

以下是我的建议：

1) 将异常处理代码放入所有 UI 事件中，然后将实际操作分配给其他方法。不要将异常处理代码分散到各处。它很笨重并且使代码难以阅读。

protected void Button1_Click(object sender, EventArgs e) {
   try {
      DoSomething();
   }
   catch Exception e {
      HandleError(e);
   }
}

2）不要这样做。您将丢失堆栈跟踪，下一个维护您代码的开发人员将追捕您。

try {
   DoSomething();
}
catch Exception e {
   throw e; // don't rethrow!!!
}

如果您不打算处理异常，就不要捕获它。或者，使用像这样的裸投：

try {
   DoSomething();
}
catch SomeException e {
   HandleException(e);
}
catch {
   throw ; // keep my stack trace.
}

3）只有在特殊情况下才抛出异常。不要将 try/catch 块作为正常流程的一部分。

4) 如果您要抛出异常，请不要抛出System.Exception。派生一个异常对象并抛出它。我经常只是一个通用BusinessException类。这样，代码的用户可以确定您创建了哪些异常以及哪些异常与系统/环境相关。

5)如果方法调用者违反了方法的约定（先决条件），则ArgumentException抛出 、ArgumentNullException、 或。ArgumentOutOfRangeException如果你发现其中之一，那就是一个编程错误。用户永远不应该看到这些异常。

如果您记得异常应该很少发生，并且处理它们几乎总是 UI 问题（因此大部分 try/catch 代码应该保留在 UI 级别），那么您会做得很好。