为什么要重新抛出异常？

Question

我已经多次看到以下代码：

try
{
    ... // some code
}
catch (Exception ex)
{
    ... // Do something
    throw new CustomException(ex);

    // or
    // throw;

    // or
    // throw ex;
}

您能否解释一下重新引发异常的目的？ 是否遵循异常处理中的模式/最佳实践？ （我在某处读过它称为“呼叫者通知”模式？）

Answer 1

如果您想记录但不处理异常，则重新抛出相同的异常很有用。

抛出一个新的异常，该异常包装了捕获的异常，对抽象很有好处。 例如，您的库使用第三方库，该库会引发您的库的客户不应该知道的异常。 在这种情况下，您可以将其包装到更本地化的异常类型中，然后将其抛出。

Answer 2

其实两者之间是有区别的

throw new CustomException(ex);

和

throw;

第二个将保留堆栈信息。

但是有时您想使Exception对应用程序域更“友好”，而不是让DatabaseException到达GUI，而是引发包含原始异常的自定义异常。

例如：

try
{

}
catch (SqlException ex)
{
    switch  (ex.Number) {
        case 17:
        case 4060:
        case 18456:
           throw new InvalidDatabaseConnectionException("The database does not exists or cannot be reached using the supplied connection settings.", ex);
        case 547:
            throw new CouldNotDeleteException("There is a another object still using this object, therefore it cannot be deleted.", ex);
        default:
            throw new UnexpectedDatabaseErrorException("There was an unexpected error from the database.", ex);
    } 
}

Answer 3

有时您想隐藏方法的实现细节或提高问题的抽象级别，以使它对方法的调用者更有意义。 为此，您可以拦截原始异常并替换一个更适合于解释问题的自定义异常。

例如，一种从文本文件加载请求的用户详细信息的方法。 该方法假定存在一个文本文件，该文件以用户ID和后缀“ .data”命名。 当该文件实际上不存在时，抛出FileNotFoundException并没有多大意义，因为每个用户的详细信息存储在文本文件中的事实是该方法内部的实现详细信息。 因此，该方法可以将原始异常包装在带有说明性消息的自定义异常中。

与显示的代码不同，最佳实践是应通过将原始异常作为新异常的InnerException属性加载来保留原始异常。 这意味着开发人员仍然可以在必要时分析潜在的问题。

创建自定义例外时，这是一个有用的清单：

•找到一个好名字来说明抛出异常的原因，并确保该名字以单词“ Exception”结尾。

•确保实现三个标准异常构造函数。

•确保使用“可序列化”属性标记异常。

•确保实现反序列化构造函数。

•添加任何可能有助于开发人员更好地理解和处理您的异常的自定义异常属性。

•如果添加任何自定义属性，请确保实现并覆盖GetObjectData以序列化自定义属性。

•如果添加任何自定义属性，请覆盖Message属性，以便可以将属性添加到标准异常消息中。

•请记住使用您的自定义异常的InnerException属性附加原始异常。

Answer 4

通常，您捕获和重新抛出该异常是出于两个原因之一，具体取决于代码在应用程序中在体系结构中的位置。

通常在应用程序的核心，您可以捕获并重新抛出异常以将异常转换为更有意义的内容。 例如，如果您正在编写数据访问层并在SQL Server中使用自定义错误代码，则可以将SqlException转换为诸如ObjectNotFoundException之类的东西。 这很有用，因为（a）使调用者更容易处理特定类型的异常，并且（b）因为它阻止了该层的实现细节，例如您使用SQL Server进行持久性泄漏到其他层的事实，让您将来更轻松地进行更改。

在应用程序的边界处，通常捕获和重新抛出而不转换异常，这样您就可以记录其详细信息，从而帮助调试和诊断实时问题。 理想情况下，您希望将错误发布到操作团队可以轻松监视的位置（例如事件日志），以及为开发人员提供控制流中异常发生位置的上下文（通常是跟踪）。

Answer 5

我可以想到以下原因：

• 作为API的一部分，将抛出的异常类型集保持固定，以便调用者仅需担心固定的异常集。 在Java中，实际上由于检查异常机制而被迫这样做。

• 向异常添加一些上下文信息。 例如，您可能希望捕获它并添加“ ...，同时处理订单号XXX，查找产品YYY”，而不是让裸露的“未找到记录”从数据库中通过。

• 做一些清理-关闭文件，回滚事务，释放一些句柄。

Answer 6

通常，“执行某些操作”要么包含更好地解释异常（例如，将其包装在另一个异常中），要么通过特定来源跟踪信息。

另一种可能性是，如果异常类型的信息不足以知道是否需要捕获异常，则在这种情况下对其进行检查将提供更多信息。

这并不是说使用此方法纯粹是出于充分的理由，当开发人员认为将来某个时候可能需要跟踪信息时，通常会使用该方法，在这种情况下，您将获得try {} catch {throw;}样式，即完全没有帮助。

Answer 7

我认为这取决于您要对异常进行的处理。

一个很好的理由是首先将错误记录在catch中，然后将其扔到UI上以生成友好的错误消息，并带有选项以查看错误的更“高级/详细”视图，其中包含原始错误。

另一种方法是“重试”方法，例如，保留错误计数，并且在经过一定量的重试之后，这是唯一一次将错误发送到堆栈上（有时是为了对超时的数据库调用进行数据库访问，或者通过慢速网络访问Web服务）。

但是，还有很多其他原因要这样做。

Answer 8

仅供参考，这是有关每种重新抛出类型的相关问题： 抛出异常的性能注意事项

我的问题集中在“为什么”我们重新抛出异常及其在应用程序异常处理策略中的用法。

Answer 9

在开始使用EntLib ExceptionBlock之前，我一直在使用它们来记录错误，然后再抛出它们。 当您认为我可以在那时处理它们时，有点讨厌，但是在那时最好让它们在UAT中严重失败（在记录它们之后），而不是掩盖一个上流的bug。

Answer 10

应用程序很可能会在调用堆栈的更高层捕获这些重新抛出的异常，因此重新抛出它们将允许更高层的处理程序在适当时进行拦截和处理。 对于应用程序来说，拥有一个顶级异常处理程序来记录或报告期望是很常见的。

另一种选择是，编码器是惰性的，他们不仅捕获了要处理的异常集，还捕获了所有内容，然后仅抛出了实际上无法处理的异常。

Answer 11

如果您将异常视为获取方法结果的另一种方法 ，那么重新抛出异常就像将结果包装到其他对象中一样。

这是在非例外世界中的常见操作。 通常，这发生在两个应用程序层的边界上-当B层的函数调用C层的函数时，它将C的结果转换为B的内部形式。

A -- calls --> B -- calls --> C

如果不是这样，那么在调用B层的A层上，将处理一整套JDK异常。 :-)

正如公认的答案所指出的那样， A层甚至可能都不知道C的异常。

例

A层 servlet：检索图像及其元信息
B层 ，JPEG库：收集可用的DCIM标签以解析JPEG文件
C层 ，一个简单的DB：一个从随机访问文件中读取字符串记录的类。 一些字节已损坏，因此引发异常，表明“无法读取记录'bibliographicCitation'的UTF-8字符串”。

因此， A不会理解“ bibliographicCitation”的含义。 因此， B应该将A此异常转换为包装原始包装的TagsReadingException 。

Answer 12

正如Rafal所提到的，有时这样做是为了将已检查的异常转换为未检查的异常，或转换为更适合API的已检查的异常。 这里有一个例子：

http://radio-weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html

Answer 13

重新抛出异常的主要原因是保持调用堆栈不变，因此您可以更全面地了解发生的情况和调用顺序。