异常处理：为何要将异常划分为Checked与Unchecked两类？

核心原因是强制区分「可预见、可恢复的外部/业务异常」和「编程错误类的运行时问题」，本质是帮开发者明确责任边界，避免无意义的异常处理代码堆砌。

一、Checked异常：必须提前处理的「可预见问题」 #

这类异常（比如IOException、SQLException）属于程序运行中完全可以预见的情况，且通常由外部环境导致，和代码逻辑无关：

• 编译器强制要求你要么用try-catch捕获处理，要么在方法签名上用throws声明抛给上层调用者。
• 目的是逼着你提前考虑这些场景：比如读取文件时必须处理「文件不存在」，调用数据库时必须处理「连接失败」——这些不是代码bug，是真实环境中可能发生的情况，你必须提前做好应对（比如提示用户检查文件、重试连接）。

二、Unchecked异常：应该避免的「编程错误」 #

这类异常（比如ArithmeticException、NullPointerException）本质上大多是代码逻辑漏洞：

• 编译器不强制处理，因为这类问题的根源是你写代码时犯的错：比如没判空就调用方法、没检查除数就做除法。正确的做法是修复代码逻辑，而不是靠try-catch兜底。
• 你提到的ArithmeticException，如果是用户输入的除数为0，那其实是「参数校验不严谨」的问题——你应该先判断输入是否合法，而不是等异常发生再处理；如果是自己代码里的逻辑导致除以零，那就是bug，直接改代码比捕获异常更有意义。

三、分类的核心意义 #

1. 明确责任：Checked异常是「外部环境/业务流程的风险」，开发者必须处理；Unchecked异常是「代码bug」，开发者必须修复。
2. 精简代码：如果所有异常都强制处理，代码会被大量无意义的try-catch淹没，可读性和维护性极差。分类后，只需要聚焦处理那些真正需要提前应对的异常。
3. 引导规范编码：Unchecked异常的存在，是在提醒你：这类问题不该靠异常处理解决，而是要通过规范的编码习惯（比如参数校验、空指针检查）来杜绝。

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