17370845950

Java异常分为检查型（如IOException）和非检查型（如NullPointerException、OutOfMemoryError），前者编译期强制处理，后者运行时出现；自定义异常应依业务语义选择继承Exception或RuntimeException，并遵循“能恢复才捕获、避免空catch、不用异常控流程”等原则。

Java异常分为两大类：检查型异常（Checked Exception）和非检查型异常（Unchecked Exception），核心区别在于编译器是否强制要求处理。

检查型异常（Checked Exception）

这类异常继承自 Exception 类（但不包括 RuntimeException 及其子类），编译器在编译阶段就会检查，必须显式处理——要么用 try-catch 捕获，要么用 throws 声明抛出。

• 典型代表：IOException、SQLException、ClassNotFoundException
• 适用场景：程序运行中可预期的外部问题，比如文件不存在、网络超时、数据库连接失败等
• 设计意图：提醒开发者“这事可能发生，你得做好准备”，属于业务流程中需要主动应对的异常

非检查型异常（Unchecked Exception）

包括 RuntimeException 及其所有子类，以及 Error 类及其子类。编译器不强制处理，运行时才暴露。

• RuntimeException：如 NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException
• Error：如 OutOfMemoryError、StackOverflowError，通常表示JVM严重问题，一般不捕获也不应恢复
• 适用场景：RuntimeException 多因编程逻辑疏漏导致，应通过代码审查和测试提前规避；Error 基本不建议捕获，而是优化资源或调整JVM参数

自定义异常的合理使用

当标准异常无法准确表达业务语义时，可扩展 Exception（检查型）或 RuntimeException（非检查型）来定义。

• 若希望调用方必须处理（如“余额不足”需明确提示并引导重试），继承 Exception
• 若属于开发阶段应避免的错误（如“非法订单状态转换”），继承 RuntimeException，便于快速暴露逻辑缺陷
• 命名清晰，提供含业务含义的构造方法（如带错误码、上下文信息）

异常处理的基本原则

不是所有异常都要捕获，也不是越细越好。关键看能否恢复、是否该由当前层处理。

• 能明确恢复的才 catch（如重试一次网络请求）；否则优先向上抛出
• 避免空 catch（catch {...} 不做任何事），至少记录日志
• 不要用异常控制正常流程（如用 NoSuchElementException 判断集合是否为空）
• 资源操作优先用 try-with-resources，确保自动关闭

基本上就这些。异常分类不是为了套概念，而是帮你在不同场景下做出更合理的处理决策。