java - 使用嵌套异常是一种好习惯吗?

标签 java exception exception-handling

这可能是一个广泛的问题,不太像 SO 风格,但如果可能的话,我仍然希望得到一些提示或指导。

我一直在查看一些遗留代码,发现其中的一部分具有嵌套在 3 或 4 层下的异常方法。
这被认为是一种正常的做法,还是应该尽可能避免这种代码风格?如果应该避免,除了增加异常处理的成本和降低可读性之外,还有什么负面影响?是否有重构代码以避免这种情况的通用方法?

最佳答案

我个人比较喜欢下面的意识形态

包装外来异常

“外来”异常是由 Java API 或第三方库抛出的异常。换句话说,您无法控制的异常。

最好捕获所有外来异常并将它们包装在适当的特定于应用程序的异常中。一旦将外来异常转换为您自己的异常,您就可以按照自己喜欢的方式传播该异常。

重新抛出已检查的异常会变得困惑

如果您的应用程序使用检查异常,重新抛出原始异常意味着重新抛出它的方法也必须声明它。

您越接近调用层次结构的顶部,就会声明抛出越多的异常。除非你只是声明你所有的方法来抛出异常。但是,如果这样做,您还不如使用未经检查的异常,因为无论如何您并没有真正从编译器异常检查中获得任何好处。

这就是为什么我更喜欢在将它们传播到调用堆栈之前捕获非应用程序特定的异常并将它们包装在应用程序特定的异常中

包装指南:异常发生的上下文可能与异常本身的位置一样重要。可以通过不同的执行路径访问应用程序中的给定位置,如果发生错误,执行路径可能会影响错误的严重性和原因。

如果您需要在将异常传播到调用堆栈时将上下文信息添加到异常,则需要使用主动传播。换句话说,您需要在调用堆栈上游的各个相关位置捕获异常,并向其添加相关的上下文信息,然后再重新抛出或包装它。

public void doSomething() throws SomeException{

    try{

        doSomethingThatCanThrowException();

    } catch (SomeException e){

       e.addContextInformation(“more info”);
       throw e;  //throw e, or wrap it – see next line.

       //throw new WrappingException(e, “more information”);

    } finally {
       //clean up – close open resources etc.
    }

}

关于java - 使用嵌套异常是一种好习惯吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14001439/

相关文章:

java - 如何调整 svg( batik )的大小并显示它?

java - Camel 文件路由不会从绝对 Uri 复制文件

python - 如何使用 pytest 测试异常和错误?

java - 管理 Java 中的异常

vba - 如何处理另一个工作簿的 Workbook_Open 事件中生成的错误?

php - 如何处理错误或异常到PHP?

c# - 为什么 LINQ 查询会在我尝试获取某种类型的计数时抛出异常

java - 从无限循环中获取值

c++ - Visual Studio 中缺少析构函数?

Java - 在方法外使用 TryCatch