Java中为何不应让方法终止程序？System.exit()相关疑问

一、理解“不应让方法终止程序——应由调用者决定是否终止程序” #

这句话的核心是职责分离：方法的核心职责是完成特定业务功能（比如示例中的计算两个整数的商），而程序的生命周期控制（是否终止）属于调用方的决策范畴。

示例代码中的quotient方法在除数为0时直接调用System.exit(1)终止程序，完全剥夺了调用者（比如main方法）的控制权——调用者既无法针对错误做自定义处理（比如提示用户重新输入），也无法继续执行后续逻辑。

二、方法直接终止程序的风险 #

• 丧失灵活性：不同场景对错误的处理需求不同。比如GUI程序遇到除数为0时，应该弹出错误提示而非直接关闭应用；批量处理任务中，应该跳过错误任务继续执行其他任务，而非终止整个进程。直接终止程序的方法无法适配这些多样的需求。
• 破坏代码复用性：如果这个quotient方法被其他模块调用，一旦触发除数为0的情况会直接终止整个程序，其他模块完全无法干预，导致该方法只能在特定场景下使用，无法复用。
• 跳过资源清理与日志记录：直接终止JVM会跳过finally块执行、线程收尾、资源释放（如文件流、数据库连接）等操作，不仅可能造成资源泄漏，还会丢失错误发生时的上下文信息，增加排查难度。

三、System.exit()的相关说明 #

1. System.exit()与Runtime.exit()的关系 #

System.exit()本质上是对Runtime.getRuntime().exit()的封装，是Java官方推荐的终止程序方式——它是静态方法，调用更便捷，语义也更明确，两者底层逻辑一致，不存在“安全性”上的本质差异。

2. System.exit()可能引发的意外问题 #

• 跳过finally块：如果方法中存在try-finally结构，调用System.exit()会直接终止JVM，finally块不会执行，导致资源无法正常释放。
• 强制中断所有线程：所有正在运行的线程（包括后台守护线程）会被强制终止，若有线程正在执行数据写入、事务提交等操作，可能导致数据损坏或不一致。
• 无法被捕获：System.exit()不会抛出异常，调用者无法通过try-catch捕获终止操作，完全失去对程序流程的控制。

四、正确的错误处理方式 #

应该通过抛出异常的方式将错误传递给调用者，由调用者决定如何处理：

class QuotientWithMethod {
    public static int quotient(int number1, int number2) throws IllegalArgumentException {
        if (number2 == 0) {
            throw new IllegalArgumentException("Divisor cannot be zero");
        }
        return number1 / number2;
    }

    public static void main(String[] args) {
        Scanner input = new Scanner(System.in);

        System.out.print("Enter two integers: ");
        int number1 = input.nextInt();
        int number2 = input.nextInt();

        try {
            int result = quotient(number1, number2);
            System.out.println(number1 + " / " + number2 + " is " + result);
        } catch (IllegalArgumentException e) {
            System.out.println("Error: " + e.getMessage());
            // 调用者可根据需求自定义处理逻辑，比如提示用户重新输入
        }
    }
}

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