C#：抛出自定义异常最佳实践

Question

我已经阅读了一些有关 C# 异常处理实践的其他问题，但似乎没有一个问题询问我在寻找什么。

如果我为特定类或一组类实现自己的自定义异常。是否应该使用内部异常将与这些类相关的所有错误封装到我的异常中，还是应该让它们失败？

我想最好捕获所有异常，以便可以立即从我的源中识别异常。我仍然将原始异常作为内部异常传递。另一方面，我认为重新抛出异常是多余的。

异常：

class FooException : Exception
{
    //...
}

选项 1：Foo 封装所有异常：

class Foo
{
    DoSomething(int param)
    {
        try 
        {
             if (/*Something Bad*/)
             {  
                 //violates business logic etc... 
                 throw new FooException("Reason...");
             }
             //... 
             //something that might throw an exception
        }
        catch (FooException ex)
        {
             throw;
        }
        catch (Exception ex)
        {
             throw new FooException("Inner Exception", ex);
        }
    }
}

选项 2：Foo 抛出特定的 FooException，但允许其他异常失败：

class Foo
{
    DoSomething(int param)
    {
        if  (/*Something Bad*/)
        {
             //violates business logic etc... 
             throw new FooException("Reason...");
        }
        //... 
        //something that might throw an exception and not caught
    }
}

Answer 1

自定义异常的目的是向堆栈跟踪提供详细的上下文信息以帮助调试。选项 1 更好，因为如果没有它，如果异常发生在堆栈中的“较低层”，您将无法获得异常的“起源”。

Answer 2

注意
选项 1：您的 throw new FooException("Reason..."); 不会被捕获，因为它位于 try / catch 块之外

1. 您应该只捕获您想要处理的异常。
2. 如果您不向异常添加任何其他数据，请使用 throw;，因为它不会杀死您的堆栈。在选项 2 中，您仍然可以在 catch 内部进行一些处理，然后调用 throw; 来使用原始堆栈重新抛出原始异常。

Answer 3

如果您在 Visual Studio 中运行“异常”的代码片段，您就有了一个良好的异常编写实践模板。

Answer 4

代码在捕获异常时需要知道的最重要的事情是系统相对于它“应该”的状态的状态（不幸的是，异常对象完全缺失了这一点）（大概是因为出现问题而抛出异常）。如果 LoadDocument 方法中发生错误，则可能是文档未成功加载，但至少有两种可能的系统状态：

1. 系统状态可能就像从未尝试过加载一样。在这种情况下，如果应用程序可以在没有加载文档的情况下继续运行，那么它是完全正确的。
2. 系统状态可能已严重损坏，最好的操作方案是将可保存的内容保存到“恢复”文件（避免用可能损坏的数据替换用户的好文件）并关闭。

显然，在这些极端之间通常还存在其他可能的状态。我建议人们应该努力拥有一个自定义异常，明确表明状态#1存在，如果可预见但不可避免的情况可能导致状态#2存在，则可能有一个自定义异常。发生并导致状态 #1 的任何异常都应该包装在指示状态 #1 的异常对象中。如果异常以系统状态可能受到损害的方式发生，则应将它们包装为 #2 或允许渗透。

Answer 5

选项 2 是最好的。我相信最佳实践是仅当您计划对异常执行某些操作时才捕获异常。

在这种情况下，选项 1 只是用您自己的异常包装异常。它没有增加任何价值，并且您的类的用户不能再仅仅捕获 ArgumentException，例如，他们还需要捕获您的 FooException 然后对内部异常进行解析。如果内部异常不是异常，他们能够做一些有用的事情，但他们需要重新抛出。

Answer 6

根据我使用库的经验，您应该将所有内容（您可以预见的）包装在 FooException 中，原因如下：

1. 人们知道它来自您的类，或者至少是他们对他们。如果他们看到 FileNotFoundException，他们可能会四处寻找。你正在帮助他们缩小范围。 （我现在意识到堆栈跟踪就是为了这个目的，所以也许你可以忽略这一点。）

2. 您可以提供更多上下文。用您自己的例外包装 FNF，您可以说“我试图加载此文件用于此目的，但找不到它。这暗示了可能的正确解决方案。

3. 您的库可以正确处理清理。如果你让异常冒泡，你就是在强迫用户清理。如果您正确地封装了您正在做的事情，那么他们不知道如何处理这种情况！

请记住仅包装您可以预见的异常，例如 FileNotFound。不要只是包装Exception并希望得到最好的结果。

Answer 7

看看这个 MSDN 最佳实践。

如果您想重新抛出捕获的异常，请考虑使用 throw 而不是 throw ex ，因为这样原始的堆栈跟踪会被保留（行号等）。

Answer 8

创建自定义异常时，我总是添加几个属性。一是用户名或ID。我添加了一个 DisplayMessage 属性来携带要显示给用户的文本。然后，我使用 Message 属性来传达要记录在日志中的技术细节。

我捕获数据访问层中的每个错误，在该级别上我仍然可以捕获存储过程的名称和传递的参数值。或者内联 SQL。也许是数据库名称或部分连接字符串（请不要提供凭据）。这些可能会出现在 Message 中或位于它们自己的新自定义 DatabaseInfo 属性中。

对于网页，我使用相同的自定义异常。我将在 Message 属性中放入表单信息 - 用户在网页上的每个数据输入控件中输入的内容、正在编辑的项目的 ID（客户、产品、员工等）以及用户的操作异常发生时正在采取。

因此，根据您的问题，我的策略是：仅在我可以对异常采取措施时捕获。很多时候，我所能做的就是记录细节。因此，我仅在这些详细信息可用时捕获，然后重新抛出以使异常冒泡到 UI。我在自定义异常中保留了原始异常。