JTest提示finally块不应通过throw退出：原因及修复方案咨询

嘿，这个问题我之前在项目里也踩过坑，JTest的这条提示其实是在帮你避开一个容易被忽略的异常处理陷阱，咱们来理清楚：

当你在finally块里直接用throw抛出异常时，会触发一个很隐蔽的问题：原始异常被覆盖。

举个例子：如果你的try块里抛出了一个业务异常，或者catch块已经捕获了一个SQLException，此时finally块执行时又抛出了MyCustomException，那么上层代码最终接收到的只会是finally里抛出的这个异常，原来的异常会完全丢失。这会让你在调试时根本找不到最初出错的原因，排查问题难度直接拉满。JTest的这条规则就是在预警这种情况。

结合你要包装自定义异常、方法已声明throws的场景，给你几个靠谱的解决思路：

方案1：保留所有异常信息，避免finally直接抛出 #

你可以在方法开头定义一个变量保存原始异常，在finally里根据是否存在原始异常来处理：

public HashMap methodName(Connection conn, HashMap hMap) throws MyCustomException {
    Throwable originalException = null;
    try {
        // 你的核心业务代码逻辑
    } catch(SQLException e) {
        originalException = e;
        mLog.error("SQL执行出错", e);
    } catch(Exception e) {
        originalException = e;
        mLog.error("未知业务异常", e);
    } finally {
        try {
            // 这里是你原本在finally里执行的操作，比如关闭资源、清理数据等
            // 示例：if (conn != null) conn.close();
        } catch(SQLException e) {
            mLog.fatal("资源清理失败", e);
            if (originalException != null) {
                // 如果之前已经有异常，把当前清理异常作为"被抑制异常"附加进去
                originalException.addSuppressed(e);
                throw new MyCustomException("业务执行失败，且资源清理出错", originalException);
            } else {
                // 如果之前没有异常，直接抛出清理失败的自定义异常
                throw new MyCustomException("资源清理失败", e);
            }
        }
        // 如果之前有异常，但finally操作没出错，这里统一抛出包装后的异常
        if (originalException != null) {
            throw new MyCustomException("业务执行失败", originalException);
        }
    }
    return hMap;
}

这种方式既保留了所有异常的上下文信息，又不会出现异常覆盖的问题，调试时可以通过getSuppressed()方法拿到清理时的异常。

方案2：用try-with-resources简化资源处理（推荐） #

如果finally块里的操作是关闭资源（比如你的Connection），Java 7+的try-with-resources语法可以自动帮你处理资源关闭，而且关闭时的异常会被自动标记为被抑制异常，不会覆盖原始业务异常：

public HashMap methodName(Connection conn, HashMap hMap) throws MyCustomException {
    // 注意：如果conn是外部传入的，try-with-resources会自动关闭它
    // 如果你不想关闭外部传入的连接，就不要用这个写法，改用方案1
    try (Connection connection = conn) {
        // 你的核心业务代码逻辑
    } catch(SQLException e) {
        mLog.error("SQL执行出错", e);
        throw new MyCustomException("业务执行失败", e);
    } catch(Exception e) {
        mLog.error("未知业务异常", e);
        throw new MyCustomException("业务执行失败", e);
    }
    return hMap;
}

这个写法更简洁，也符合Java的最佳实践，能从根源上避免finally块抛异常的问题。

方案3：临时禁用JTest规则（不推荐） #

如果你的场景确实有特殊需求，必须在finally里抛异常，且你确认不会丢失关键异常信息，可以在JTest中禁用这条规则。但这是下策，因为这条规则的设计就是为了帮你避免调试困难，除非万不得已，不建议这么做。

内容的提问来源于stack exchange，提问作者Tejas