java - "switch"相当于异常处理

Question

这不是关于一般异常处理的问题，但它特别适用于某些框架的使用。几个典型起点的例子:

• GWT:public void onFailure(Throwable caught)实现 AsyncCallback界面。
• JAX-RS:public Response toResponse(E throwable)实现 ExceptionMapper<E extends Throwable>界面。

上述两种方法都接收一个 Throwable 的实例.通常，我见过开发人员使用简单的“if/else if” block 来区分处理逻辑:

// As specified by the AsyncCallback class of the GWT framework
public void onFailure(Throwable caught) {
    if (caught instanceof AnException) {
        // handle AnException
    } else if (caught instanceof AnotherException) {
        // handle AnotherException
    } else if (caught instanceof YetAnotherException) {
        // handle YetAnotherException
    } else if (caught instanceof ...) {
        // and so on...
    }
}

由于很多原因我不是“if/else if” block 的粉丝，我想出了以下“模式”，它将“if/else if” block 转换为“try/catch” block ，表现就好像它是一个“开关” block :

public void onFailure(Throwable caught) {
    try {
        throw caught;
    } catch(AnException e1) {
        // handle AnException
    } catch(AnotherException e2) {
        // handle AnotherException
    } catch(YetAnotherException e3) {
        // handle YetAnotherException
    } catch(...) {
        // and so on...
    }
}

我的问题是:使用这种方法是否有任何缺点 - 在性能、最佳实践、代码可读性、一般安全性或我没有考虑或注意到的任何其他方面？

Answer 1

在正常 情况下使用异常来 Bootstrap 流是一种代码味道，但这并不是您在这里所做的。我认为您可以摆脱这种情况，原因如下:

1. 我们已经出于各种原因捕获并重新抛出异常(例如，“捕获、采取一些行动、传播”)。这在意图上有点不同，但在成本方面并不差。

2. 您已经承担了此异常被抛出的代价至少一次。您可能已经承担了其原因被抛出、捕获、包装或重新抛出的成本。填充堆栈跟踪的成本已经支付。再次重新抛出已填充的异常不会增加复杂度。

3. 您没有使用异常来引导正常 代码路径的流动。你正在对一个错误使用react，所以你已经在异常路径上，你应该很少(如果有的话)结束在这里。如果此模式效率低下，除非您遇到很多 异常，否则这无关紧要，在这种情况下您会遇到更大的问题。花时间优化您期望采用的路径，而不是优化您不希望采用的路径。

4. 从美学上讲，很少有东西像长链的 if/else if block 那样让我毛骨悚然，尤其是当条件仅仅是类型检查时.在我看来，您提出的建议更具可读性。具有多个有序的 catch 子句很常见，因此结构大部分都是熟悉的。 try { throw e; 序言可能是非正统的，但它很容易推理。

传播 Throwable 时要小心。一些错误，如 VirtualMachineError 层次结构，是出现严重错误的标志，应该允许它们继续运行。其他异常，如 InterruptedException，传达有关原始 线程状态的信息，不应在不同 线程上盲目传播它们。有些，如 ThreadDeath，跨越这两个类别。