返回异常是否属于反模式？结合代码示例咨询技术问题

咱们直接说结论：这种通过返回Throwable对象代替抛出异常的写法，确实是一种典型的代码反模式。接下来结合你的代码具体分析问题所在，以及怎么优化。

为什么这是反模式？ #

• 违背Java异常体系的设计初衷：Java本身就提供了throw/catch的标准化错误处理机制，专门用来区分正常流程和错误流程。返回异常对象相当于绕开了这套成熟的机制，其他开发者读代码时得额外理解你这套自定义的错误传递逻辑，平白增加认知负担。
• 错误容易被忽略：如果调用serviceUp()的人忘了检查返回值是否为null，直接跳过错误处理，就会埋下隐形bug。而标准的异常抛出机制要么要求调用者捕获处理，要么要求声明抛出，不会轻易漏掉错误。
• 代码语义混乱：serviceUp()这个方法名，从字面意思看应该是“启动服务”的动作方法，但它却返回异常对象，这种行为和命名的不匹配会让代码逻辑变得晦涩难懂。

怎么优化你的代码？ #

核心思路是重构你的私有辅助方法serviceUp()，让它回到标准的异常处理方式，然后再调整业务方法：

首先重构serviceUp()，让它在失败时直接抛出异常，而非返回：

private void serviceUp() throws ServiceUnavailableException {
    // 模拟服务检查逻辑
    if (!isServiceRunning()) {
        // 根据实际场景定义具体的异常类型，比通用Throwable更清晰
        throw new ServiceUnavailableException("服务未启动");
    }
    // 服务正常时的初始化逻辑
}

然后调整你的两个业务方法：

1. 出错时继续执行的场景（proceedWhenError） #

public void proceedWhenError() {
    try {
        serviceUp();
        // 服务正常时的业务逻辑
    } catch (ServiceUnavailableException e) {
        logger.debug("服务启动失败，但不影响后续执行", e);
        // 出错时的替代业务逻辑
    }
}

2. 出错时终止执行的场景（doNotProceedWhenError） #

public void doNotProceedWhenError() {
    try {
        serviceUp();
        // 服务正常时的业务逻辑
    } catch (ServiceUnavailableException e) {
        // 出错时的收尾逻辑（比如释放资源）
        throw new IllegalStateException("无法继续执行：服务未启动", e);
    }
}

有没有例外情况？ #

极少数特殊场景下，返回异常可能是合理的——比如批量处理任务时，需要收集所有错误再统一上报的场景，但这时通常也会用List<Throwable>这类集合来返回，而非单个Throwable对象。但对于你当前的业务场景来说，显然用标准的异常抛出机制更清晰、更符合Java的编码规范。

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