为何单进程内抛出（throw）并捕获（catch）消息并非良好实践？

1. 违背异常机制的设计初衷 #

异常从诞生起就是用来处理意外错误场景的——比如IO读写失败、空指针访问、非法参数输入这类超出正常业务流程的情况。如果用它来传递预期内的业务消息（比如“通知模块完成初始化”“告知库存充足”），完全扭曲了代码语义。其他开发者看到catch块时，第一反应是处理错误，结果里面却是正常业务逻辑，理解成本会飙升。

2. 性能开销远超常规流程控制 #

异常的抛出和捕获是重量级操作：以Java为例，JVM需要生成完整的栈跟踪信息，遍历调用栈寻找匹配的catch块，这个过程的耗时比普通函数调用、回调或者状态变量传递高几个数量级。如果频繁用这种方式传递消息，会明显拖慢程序运行效率。

3. 代码可读性与可维护性极差 #

• 异常属于“非本地跳转”，调用栈中的中间函数可能完全不知道自身代码会被异常打断，调试时很难跟踪流程——你得跟着异常栈一步步回溯，不像普通分支或回调那样直观。
• 容易出现隐藏的流程路径：比如某个catch块误捕获了不该处理的异常，或者遗漏了异常处理逻辑，导致bug难以定位。
• 业务逻辑被拆分到try/catch块中，和错误处理代码混在一起，主流程变得混乱不堪，后续修改时很容易引入新问题。

4. 流程控制不可预测 #

异常可以跨越多个函数层级传递，一旦抛出，你很难精准控制它会被哪个catch块捕获。在复杂的代码结构里，如果多个地方都捕获同类型异常，很容易出现逻辑冲突或者意外的流程跳转，导致业务逻辑偏离预期。

5. 资源泄漏风险提升 #

如果在try块中打开了文件句柄、数据库连接这类资源，异常抛出时如果没有在finally块中正确释放，很容易导致资源泄漏。虽然这是异常使用的通用问题，但用异常做消息传递时，流程跳转更随意，开发者更容易忽略资源清理步骤。

反例（Java）：用异常做流程控制 #

public void processOrder() {
    try {
        checkInventory();
        chargePayment();
    } catch (InventoryLowException e) {
        notifyCustomerOutOfStock();
    }
}

private void checkInventory() {
    if (stock < 1) {
        throw new InventoryLowException();
    }
}

正确做法：用返回值处理预期场景 #

public void processOrder() {
    boolean hasStock = checkInventory();
    if (!hasStock) {
        notifyCustomerOutOfStock();
        return;
    }
    chargePayment();
}

private boolean checkInventory() {
    return stock >= 1;
}

总结：异常是处理意外错误的工具，绝非普通消息传递或流程控制的手段。用它干这类事，会带来性能、可读性、维护性等一系列问题，完全得不偿失。

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