Question

在java中有可能重新抛出异常，但它有什么优势吗？

Answer 1

当你想要重新抛出异常的一个例子是当你真的不知道如何自己处理它时，但你想记录抛出异常。重新调整它可以捕获您需要记录的堆栈信息，并将异常传递给调用堆栈以供调用者处理。

Answer 2

不确定。如果您需要对异常执行一些特殊处理（日志记录，清理等），但无法完全“处理”它，则通常会进行处理，然后重新抛出异常。请注意，在许多情况下（特别是清理资源），您可能需要finally子句而不是catch / rethrow。

Answer 3

有时，您希望方法抛出特定类型的Exception，但是很少有实例会导致在方法中抛出其他异常。我经常用我想要的Exception包含因果异常，然后重新抛出所需的异常。

如果在控件传递给调用方法（或其中一个祖先）之前无法确定异常导致操作失败，那么这非常有用，因为如果进程最终失败，我可以追溯到在堆栈跟踪中看到原因。

Answer 4

我多年没有做过Java，但是从我记忆中看，它就像其他语言一样有异常和OO。异常可以是子类，通常，您需要捕获许多异常的基类，但可能无法处理所有异常。所以说你正在处理一个远程文件传输，并想要捕获所有IOErrors，因为你处理了大部分，但不是DiskFull。你可以重新抛出这个，让其他人在链上进一步处理它，但通过重新传输来处理其他问题，比如TransmissionFailed。

Answer 5

如果你能以某种方式证明你需要重新抛出同样的异常，我认为你的设计有问题。

捕获一个异常并重新抛出另一个异常非常有意义。例如，您可能希望添加原始异常没有的详细信息。

Answer 6

真实案例

以下是我需要重新抛出java异常的一些真实情况：

在进行JDBC调用时，我会捕获一个SQLException。但是，postgres会抛出一个带有额外数据和状态的PSQLException。在测试边缘情况时，我们能够破坏数据库，我们希望记录器具有关于异常和状态的非常具体的数据。我们将原始异常包装在一个新的异常中，其中包含有关服务器状态和重新抛出的更多数据。
在实现文本解析器时，我希望捕获一些运行时解析异常，例如NumberFormatException，并将它们传递给堆栈，其中包含有关文本引起的文本和导致解析异常的文本来源的其他数据。
我的同事告诉我一个项目，他在其中工作的地方，每个异常都被包装在另外两种类型中的一种--RetryableException和FatalException。在可重试异常的情况下，应用程序将等待并在一段固定的时间后重试该操作。 我不太确定我对这个设计的看法，但我认为这是处理一些交易问题的一个障碍。
在某些情况下，我会使用一个现有的API，它有一个针对高级异常定义的抛出，我会做一个操作，抛出一个无关的异常（我觉得它真的属于RuntimeException） - 然后我将重新抛出异常作为更一般异常的原因。

我可以想到的最纯粹的案例，您可能想要重新抛出异常，当您想要向其添加其他数据时。例如：

public bizMethod() throws CoolBizLogicException {
    int policyId = getPolicyId("bar");
    try {
      coolBizLogic(foobar); // this throws an exception
    }
    catch (CoolBizLogicException cble) {
      cble.setPolicyId(policyId);
      throw cble;
    }
}

Answer 7

我不这么认为。如果你无法处理它，就不要抓住它。

在Java中重新抛出异常

7 个答案:

真实案例