Java中ArithmeticException为何属于非受检异常？为何划分两类异常？

1. 为什么ArithmeticException属于非受检异常？ #

首先得明确Java的异常分类规则：所有继承自RuntimeException的异常都属于非受检异常，而ArithmeticException正是RuntimeException的直接子类。

更深层的原因在于这类异常的本质——它几乎完全由编程失误导致。比如最常见的场景是除数为0的操作：这是开发者在编码时完全可以通过提前判断（比如检查除数是否为0）来避免的问题，而非那种依赖外部环境（如文件不存在、网络中断）无法完全规避的异常。

Java设计时将这类异常归为非受检，就是不想强制开发者对这类明显的编码失误进行捕获或声明。如果强制这么做，代码会被大量不必要的try-catch块填满，反而降低可读性和开发效率。正确的做法是在编码阶段就通过逻辑判断规避这类问题，而非靠异常处理兜底。

2. Java中为何要定义受检异常与非受检异常这两种类型？ #

这个设计的核心是区分异常的性质和处理责任，主要有以下几个原因：

• 区分"可预见的外部错误"和"编程失误"
  受检异常（比如IOException、SQLException）通常是程序依赖外部资源或环境时产生的异常——即便代码逻辑完全正确，也可能因为文件被删除、数据库连接中断等外部因素触发。这类异常必须被显式处理（捕获或向上声明），目的是强制开发者考虑这些场景，保证程序的健壮性。
  而非受检异常则源于编码错误，比如空指针、数组越界、除以零——这些是开发者可以通过规范编码避免的问题，Java不强制处理，就是为了提醒开发者：应该从根源上修正代码，而非用异常处理掩盖错误。

• 提升代码可读性与API清晰度
  当你调用一个声明了受检异常的方法时，立刻就能知道这个方法可能遇到哪些外部风险，需要提前做好处理。比如调用FileInputStream的构造方法，IDE会提示你必须处理FileNotFoundException，这相当于API在明确告诉你："我可能找不到文件，你得想好怎么应对"。
  反之，非受检异常不需要声明，不会让方法签名变得臃肿，同时也暗示开发者：这类问题是你自己的代码问题，要自查修正。

• 平衡开发效率与程序健壮性
  如果所有异常都强制处理，代码会变得繁琐不堪；如果所有异常都不强制处理，又会导致开发者忽略那些不可控的外部风险。拆分两种异常类型，让开发者可以把精力放在真正需要处理的外部异常上，同时专注于修正自身的编码错误。

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