包装例外是好的做法吗？ [关闭]

public Record GetRecord(string id)
{
    _dbContext.Records.First(r => r.Id == id);
}

public Record GetRecord(string id)
{
    try
    {
        _dbContext.Records.First(r => r.Id == id);
    }
    catch(InvalidOperationException ex)
    {
        throw new ApplicationException(string.Format("No record found with id: {0}". id), ex);
    }
}

#1 楼

没有理由这样做。如果您在日志中包括stacktrace，则您已经知道问题所在。您唯一想念的就是您可能从不同渠道知道的输入（通常不需要找出问题）。

请注意，您的示例返回void，这可能不是如您所愿，我应该说我要进行的更改是使用.FirstOrDefault()而不是First，它将返回默认值-引用类型的null。然后，您可以进行简单的null检查，以查看是否返回了记录，而不必开始使用try-catches。

是的，您可以执行所有这些操作以提供特定的错误消息。我个人不喜欢它，我更喜欢从代码本身派生它（例如通过前面提到的null检查）。

#2 楼

这取决于您希望如何向最终用户呈现错误状态。

经验法则：始终记录原始异常（该异常是较低级别的，并且通常是相当技术性的，会吓到非技术性用户）。但是，请将这些异常包装在更加用户友好的异常（更高级别）中，并使用通俗易懂的语言并让用户易于理解的消息。

您不需要（也不能）对每个可能的异常都执行此操作，但是通常应该对合理预期会发生的错误状态执行此操作。在您的示例中，如果仅当不存在带有用户输入记录ID的记录时才生成InvalidOperationException，则将其包装在友好消息中是合理的，例如“找不到ID为xyz的记录”。 。

同样，当连接到数据库时遇到任何问题时，也可以期待SqlException，除非您的用户群是技术人员并且了解SQL，数据库等，否则最好将它们包装在更高级别带有友好消息的异常，例如“出现问题。请检查您的网络连接。如果再次出现问题，请与系统管理员或软件供应商联系。”。

取决于应用程序如何显示错误状态对于用户而言，“更多详细信息”视图可以显示原始异常和完整堆栈跟踪（作为包装异常中的原因附加），但是默认情况下应隐藏此类视图。这具有一些优点。现场支持人员可以立即查看原始异常，而无需检查日志。并且如果用户恰好是技术人员（通常是非技术用户），则用户也可以通过电话支持更好地描述错误。

还请避免使用硬编码字符串（如果您还没有避免使用它们）。它使它们不可重用且不可本地化。


有关检查数据有效性的注意事项：

阿巴斯建议只允许为意外行为生成异常，然后继续给出如何检查记录是否存在的替代方法（因为预期可能存在或可能不存在记录这一事实，这并非意外）使用异常。虽然这通常是理想的，并且对于简单的检查很有效，但我建议不要将其用于更复杂的检查，例如尝试将用户输入的字符串解析为数字。

用户输入的字符串可以是预期不能代表数字，并且将其解析为数字可能会失败。您可能很想在解析之前编写正则表达式检查以对字符串执行操作，但不仅是您尝试复制该语言已提供的内容，还可能会遗漏边缘情况并仍然获得解析异常-而且这不会使您的崩溃完全应用。在这种情况下，最好盲目尝试使用该语言的标准解析方法进行解析，并生成一个异常，然后通过警告用户输入的字符串不是有效数字来处理该异常。

但是，如果该语言的标准解析库提供了测试解析和正常失败的方法，则可以使用它们而不是自己测试解析和捕获异常。正如阿巴斯在评论中指出的那样，C＃中有一个TryParse方法，其功能与阿巴斯答案中提出的TryGetRecord方法类似。 Java中不存在类似的实现（主要是由于缺少out参数），其中捕获异常是正确的方法。

#3 楼

我认为您的故事有两个方面：

1。包装异常

这在发生不同类型的异常并且您想要区分它们的情况下很有用，当然当您要为每种异常提供特定的错误消息时。正如您已阅读自己的内容一样，这样做时最好遵循Microsoft给出的指导。我：

2。引发异常还是不引发异常

首先，这是.NET Framework中异常的定义（来自MSDN）：


异常是任何错误条件或正在执行的程序遇到的意外行为。由于您的代码或您调用的代码中的错误（例如，共享库），操作系统资源不可用，公共语言运行库遇到的意外情况（例如，无法验证的代码）等等，可能引发异常。 。


如果仔细阅读此书，您将会理解，异常情况发生时会发生异常，而您通常无法控制这些事情。

在您的示例中，对于给定的ID，不存在用户这一事实并非意料之外的代码行为。这只是意味着数据库中没有该ID的数据。尝试获取具有给定ID（显然将返回null）的对象并对其执行某些方法或从属性获取值时，这将导致异常。在这种情况下，这将是NullReferenceException。

我建议您将代码重写为以下内容：找到后，将返回默认类型。由于Record是引用类型，因此将为null。现在您所要做的只是一个空
-检查使用此方法时。您还可以使用out参数，并使该方法返回布尔值。这样可以很容易地进行检查：

public Record GetRecord(string id)
{
    var foundRecord = _dbContext.Records.FirstOrDefault(r => r.Id == id);
}

然后用法：我偏离了Exception主题，但我认为这可能会帮助您重构代码。请记住，异常适用于您的代码执行意外的操作。 Ecxeption处理用于捕获可能导致程序异常行为的情况，而不是针对您（而非代码）期望的数据。希望您能理解我的意思，对您有所帮助！ ;）

#4 楼

本质上，抛出异常可能会发生两件事：


它可以在调用堆栈中进一步处理
它可以保持未处理状态，要么冒泡直到发生导致应用程序崩溃或被吞下并记录（可能已采取一些非常通用的高级步骤来处理它可能留下的任何无效状态）

所以，让我们考虑一下这两个，以及异常包装如何适用于它们。

未处理的

对于未处理的异常，通常提供以下三个重要信息：

堆栈跟踪
消息
异常类型

实际上，在这一点上，异常类型实际上只是人类的一个特定部分，可读信息，而堆栈跟踪只是有关问题发生位置的进一步信息。因此，实际上，这三个都是相同的东西-为必须走过来并了解出了什么问题的人提供的诊断信息。

因此，这里包装异常的目的是提供更好的诊断信息。也许存在一些变量，可能与尝试找出发生的事情有关。指定特定类型的异常也可以提供重要信息（例如，知道问题是由数据库引起的）。

牢记这一点，让我们比较示例中的两个异常：


ApplicationException(string.Format("No record found with id: {0}". id), ex);
ApplicationException("An error occurred while processing the record"), ex);

两者都是ApplicationException，在任何情况下都没有那么大的帮助。但是第一个提供了有用的信息：找不到记录，以及该记录的ID。这立即意味着调试人员可以查看数据库的状态，或尝试了解为什么将错误的ID传递给此方法。尽管有人可以得出结论，仅从堆栈跟踪中找不到记录，但是他们无法获取ID，因此消息实际上只是一种人类可读的方式，可以显示潜在的重要信息。

另一方面，第二个没有提供任何有用的信息。 “发生了错误”，嗯，我们已经知道了。 “在处理记录时”-这只是对从堆栈跟踪中得到的内容的模糊重述。当我们抛出一个可能被处理的异常时，就会出现一个新的，非常重要的问题：抽象级别。这就是MSDN报价的含义。

作为示例，让我们以良好的旧“存储库”抽象为例，其中有一个IRepository，它使消费者不必担心数据如何持久化。是的，实际上，编写一个应用程序需要交换完全不同类型的持久性常常是不现实的，但这是一个很好的例子。具体的存储库类：SqlRepository和FileRepository。前者将Record作为一行存储在数据库的表中，并以id为键。第二个将Record作为序列化的文本存储在名为{id} .txt的特定目录的文本文件中。

现在让我们看一下我们的GetRecord方法。如果我将无效的id传递给这两个参数，会发生什么？好吧，它们都抛出异常，但是都抛出完全不同的异常类型。一个可能抛出一个InvalidOperationException（如果像示例中那样使用IQueryable）或另一个SqlException，另一个则抛出FileNotFoundException。那个IRepository抽象层，突然我们的抽象就泄漏了。在不了解IRepository所有可能的实现方式的情况下，没有任何调用者希望明智地处理这些问题。实际上，他们不仅需要了解广泛的类，而且还需要非常具体的实现细节。基于SQL的存储库是否抛出InvalidOperationException或SqlException？基于文件的存储库是否抛出FileNotFoundException或DirectoryNotFoundException？

因此，为了保持其抽象性，存储库都应抛出可被调用代码理解的异常。如果他们需要使用特定类型的异常来发出特定问题的信号，则这应该是一个常见异常，该异常以捕获器理解的抽象级别（“未找到记录”）描述该问题，而不是抛出器理解的抽象级别（ “找不到文件”，“找不到Sql记录”。有用的信息仅在消息中提供。假设我们不打算解析该消息以从中获取有用的信息（这将是一种非常复杂且容易出错的处理方式），那么调用者将无法对这些异常做任何有用的事情。 ApplicationException没有指定任何错误信息。

另一方面，YAGNI在这里非常重要。如果您控制调用此方法的代码，并且知道不会处理此类异常，那么不费吹灰之力定义自定义异常类型然后将其忽略将是毫无意义的。但是关键是在编写引发可能由其使用者处理的异常的代码时，确保以正确的抽象级别抛出异常是包装的一个很好的理由。

结论

这比我预期的要长，所以仅再次重申其充分的理由：


为以后的调试/诊断提供重要的信息，但包装的异常无法提供这些信息
确保对于可以通过调用代码合理地处理的异常，该异常以正确的抽象级别提供信息。

其中，后者的情况要多得多，在示例中您的问题，可能不会引起关注。不过，前者是第一个例外与您的“为什么也不要”示例之间的关键区别功能。通过上述一个或两个原因提供重大价值。

#5 楼

我认为对于第一种情况，您应该遵循@Jeroen的建议并使用FirstOrDefault，因为异常处理非常昂贵，您不想每次都可能发生异常。

如果您真的想包装异常，则不要使用ApplicationException包装异常，因为它非常抽象。每个异常都是一个ApplicationException。

现在，如果您仍然确定要引发异常，则应使用自定义异常。当您的数据存储中不存在您的ID时，出现在RecordNotFoundException的某行。此异常清楚地表明未找到记录，并且使用您的API的开发人员将立即理解该记录（如果未找到，则您会遇到另一种问题！）。

关于SqlException，我真的不认为您应该在此级别上接受它。您应该让客户端（UI，Web服务等）决定如何处理SqlException，因为您无法控制它。

#6 楼

@TopinFrassi对此有所提示，但是您应该准备好未找到记录，因此您应该将该代码编码到应用程序中，不要使其成为异常。

public Record GetRecord(string id)
{
    try
    {
        _dbContext.Records.First(r => r.Id == id);
    }
    catch(InvalidOperationException ex)
    {
        throw new ApplicationException(string.Format("No record found with id: {0}". id), ex);
    }
}

而不是这样做，您只需要添加if语句

public Record GetRecord(string id)
{
    if (_dbContext.Records.First(r => r.Id == id).Any())
    {
        return _dbContext.Records.First(r => r.Id == id);
    }
}

，但这将调用查询两次

您甚至应该尝试调用GetRecord方法之前，就应该已经有一个布尔方法检查数据库中的记录开始。

public Record GetRecord(string id)
{
    return _dbContext.Records.First(r => r.Id == id);
}

public boolean DoesRecordExist(string id)
{
    retrun _dbContext.Records.First(r => r.Id == id) ? true : false ;
}

var id = "42"; // should be passed in somehow
Record recordIWant;
if (DoesRecordExist(id))
{
    recordIWant = GetRecord(id);
}
else
{
    /*Handle issue*/
}

在尝试检索不存在的记录的情况下，您应该在输入时而不是在实际记录时真正地处理此问题检索

，因此您应该做的是在用户输入错误ID或输入错误ID时提醒用户，这样应用程序将不允许用户通过不显示在断开记录中的内容来选择该项目第一名

#7 楼

除非您有充分的理由将它们包装起来，否则这是一个不好的做法。除非确定当前的意图和实现都是合理的，否则不要包装异常。不要为将来的偶然事件或其他未经证明的收益而包装异常。

当您想包装异常时的一些示例： t是一个真正的异常，但是是一个结果，但是您使用的库错误地使用异常来表示结果。然后，将特定异常替换为结果，例如null或false。您应该在调用库后立即执行此操作。
当某些东西在控件之外使用两个实现时，会抛出相同的可操作异常，但每个都使用自己的表示形式。您可能希望将这两个异常中的每一个包装到一个统一的异常中。这是一种非常罕见的情况，但有时会发生。
在事件发生期间，任何异常都可能是可操作的或结果。通常，尽管您希望在调用方中而不是在被调用方中使用此方法。
在将异常传递到应用程序之外时。您的应用程序的异常可能仅包含有关开发人员和日志记录的信息。如果是这样，则在将其传递到应用程序之外时，则不想传递此数据。通常用标记为passthru的异常替换所有异常，这些异常会在记录一次日志后删除要记录的数据并给出通用消息。您通常想让用户知道出了点问题，请联系支持和信息以帮助查找日志（通常是最小时间戳，有些人可能会加密日志）。在当前图层上方的图层中进行操作，但是它所源自的图层并不知道这一点。这种情况很少发生。如果源代码是可以编辑的代码，通常仍然可以找到在源代码处标记异常的方法。
在极少数情况下，您可能想添加更多有意义的信息。例如，在执行X时发生SQL错误。问题在于这是人们在认为有用之前先添加信息，并且除了包装外还有其他方法（您的异常是类，您可以添加各种内容，例如堆栈信息）。通常，人们会优先考虑弥补异常，而不是识别和修复错误。
从控件之外的来源接收到异常时，您想用更灵活的异常类型替换它。这仅应发生在边界上，并可能导致不必要的复杂性。与上面类似。不要包装可以添加的异常。不幸的是，在大多数语言中，设置基本异常并不是一件容易的事。

它往往是包装异常的反模式。人们之所以喜欢这样做，是因为事情应该不了解底层的实现。实际上是：


学科上的问题。要么不按需包装异常，要么不知道何时使某方面的知识多于不应有的层次。在很多情况下，人们可能会担心他们不应该一开始就抛出的异常。通常，您会让用户单击此控件，但是在显示该控件之前您不检查先决条件，而是依靠异常将其精美地呈现给用户。
反效果。通过将下面的层中的所有异常包装到自己的层中，您最终制作了一个本应不知道实现的层。
不必要。当您看到未处理的异常（它们到达顶部时除外）被包裹时，它们什么也没做。您刚刚添加了许多新类，尝试了catch等等，但是同样的事情来了。您要做的就是从概念上重命名某些内容。
最终会破坏/隐藏信息，使其变得模棱两可或难以获取。
通常最终会出现使用异常包装重新实现堆栈跟踪的情况。最终将成为不必要地在较低级别上多次实施顶级异常处理的结果。否则为时过早。

不，这不是一个好习惯。这是一个坏习惯。这也是您可能需要在蔚蓝的月亮中做一次的事情。