209. Java 异常 - 何时用检查异常？何时用未检查异常？
在 Java 编程语言中，非检查异常（如 RuntimeException 及其子类）不会强制要求方法捕获或声明它们。这种设计可能导致程序员倾向于只使用非检查异常，或者让所有自定义的异常类都继承自 RuntimeException。虽然这样做可以避免编译器错误，并且不需要特别指定或捕获异常，但这种做法绕过了异常处理的本意，可能会给使用这些类的其他开发者带来问题。
为什么 Java 设计者要强制方法声明可能抛出的检查异常？
方法中可能抛出的任何异常都是该方法的公共接口的一部分。当其他开发者调用这个方法时，他们必须知道这个方法可能抛出的异常，这样才能决定如何处理这些异常。异常就像方法的参数和返回值一样，是方法接口的一部分。
为什么不要求也声明运行时异常？
如果声明方法的 API 是有益的，为什么不要求也声明 运行时异常（RuntimeException）呢？这是因为运行时异常通常表示编程错误，而调用方法的客户端代码通常不能合理地从这些异常中恢复或进行处理。常见的运行时异常包括：
- 算术异常（如除以零）
- 空指针异常（尝试通过 null 引用访问对象）
- 数组下标越界异常（尝试使用不正确的索引访问数组）
运行时异常可以在程序的任何位置发生，在大多数程序中，它们可能非常频繁。如果每个方法声明都要求列出所有可能抛出的运行时异常，那么程序的代码会变得非常繁琐，降低了代码的可读性和可维护性。因此，编译器不要求开发者捕获或声明运行时异常（尽管你可以声明）。
何时应该抛出运行时异常？
有时，抛出 RuntimeException 是因为方法的调用者传递了无效的参数。例如，当方法检测到参数为 null 时，可以抛出 NullPointerException（这是一种未检查异常）。这通常是表示程序逻辑错误，而不是期望的、可以恢复的异常。
示例：方法参数为 null 时抛出 NullPointerException
public void processData(String data) {
if (data == null) {
throw new NullPointerException("Data cannot be null.");
}
// 处理数据逻辑
}
在这个例子中，如果 data 参数是 null，程序会抛出一个 NullPointerException，表示方法调用者传递了无效参数。此时，调用者无法恢复，只能修正代码。
不要为了避免指定异常而使用运行时异常
通常来说，不应仅仅因为不想麻烦地指定方法可能抛出的异常而使用 RuntimeException 或其子类。异常应该根据实际情况合理选择。如果异常是程序错误，调用者无法恢复，就应该使用未检查的异常；如果异常是可以被恢复的，则应该使用检查异常。
何时使用检查异常？
- 当客户端可以合理地恢复异常时，应该使用检查异常。举个例子，当文件操作失败时，客户端可以捕获异常并提示用户重新尝试或者提供备用路径，这种情况下应该使用检查异常（如
IOException）。
何时使用未检查异常？
- 当客户端无法恢复异常时，应该使用未检查异常。比如，除以零、空指针异常等，这些通常表示程序中的 bug，调用者无法采取任何有效的措施进行恢复。
结论：如何选择异常类型？
- 可以恢复的异常：当异常是程序逻辑的一部分，且调用者有能力采取措施来恢复或处理时，应使用 检查异常（如
IOException）。 - 无法恢复的异常：当异常表示程序中的错误，调用者无法处理或恢复时，应使用 未检查异常（如
NullPointerException）。
小贴士
- 不要将未检查异常滥用为“简化代码”。过多地使用
RuntimeException会降低代码的可维护性，因为它隐藏了潜在的错误和异常情况，给调用者带来隐性的风险。 - 清晰的异常设计：始终确保你的代码能够清晰地表达何种情况是可以恢复的，何种情况是致命的错误。通过合理使用检查和未检查异常，你的
API会更具可用性和可维护性。
