Java异常类分为Error和Exception，Error指JVM无法处理的严重问题，如OutOfMemoryError和StackOverflowError；Exception包括编译时必须处理的Checked Exception（如IOException、SQLException）和运行时的Unchecked Exception（如NullPointerException、ArrayIndexOutOfBoundsException）。选择异常类应根据问题具体性，可自定义继承Exception或RuntimeException。最佳实践包括：只捕获可处理的异常、不忽略异常、使用try-with-resources、避免finally块抛异常、记录详细日志。应在无法处理错误时抛出异常，但避免滥用以影响性能。
常见的异常类，简单来说，就是程序运行过程中可能遇到的各种“不正常”情况的类型。它们是Java异常处理机制的基础，理解这些异常类能帮助我们更好地编写健壮的代码。
解决方案
Java的异常类主要分为两大类：Throwable 的子类 Error 和 Exception。
Error: 通常指的是JVM（Java虚拟机）级别的错误，例如
OutOfMemoryError（内存溢出）、StackOverflowError（栈溢出）等。这类错误通常是程序无法处理的，只能通过调整JVM参数或者修改代码来避免。 举个例子，如果你递归调用一个方法，没有设置合适的退出条件，很可能就会导致StackOverflowError。 我曾经遇到过一个项目，由于日志文件配置不当，导致日志文件无限增长，最终耗尽了所有内存，引发了OutOfMemoryError。 这种情况下，我们需要检查并修正日志配置，而不是简单地捕获这个错误。-
Exception: 表示程序可以处理的异常。 Exception又分为两种：
-
Checked Exception（受检异常）： 这类异常在编译时就需要处理，要么使用
try-catch块捕获，要么使用throws关键字声明抛出。 例如IOException（输入输出异常）、SQLException（数据库异常）等。 如果你试图读取一个不存在的文件，就会抛出IOException。 编译器会强制你处理这个异常，否则代码无法通过编译。 -
Unchecked Exception（非受检异常）： 这类异常在编译时不需要强制处理，通常是由于程序逻辑错误导致的。 例如
NullPointerException（空指针异常）、ArrayIndexOutOfBoundsException（数组越界异常）、IllegalArgumentException（非法参数异常）等。NullPointerException应该是每个Java程序员都遇到过的噩梦。 我曾经在处理一个复杂的对象关系时，忘记对某个对象进行判空，结果在调用该对象的方法时，就抛出了NullPointerException。 这类异常需要我们仔细检查代码逻辑，避免出现空指针。
-
Checked Exception（受检异常）： 这类异常在编译时就需要处理，要么使用
常见的RuntimeException（非受检异常）的子类：
-
NullPointerException: 当在需要对象的地方使用了
null时抛出。 这个异常太常见了，以至于很多IDE都提供了自动判空的功能。 - ArrayIndexOutOfBoundsException: 当访问数组时，使用的索引超出了数组的范围时抛出。 我曾经在循环遍历数组时，由于循环条件设置错误，导致访问了数组的最后一个元素之后的位置，引发了这个异常。
- IllegalArgumentException: 当方法接收到的参数不合法时抛出。 例如，你可能需要验证输入的参数是否在某个范围内，如果不在，就抛出这个异常。
- NumberFormatException: 当试图将一个字符串转换为数字，但字符串的格式不正确时抛出。 例如，你试图将 "abc" 转换为整数，就会抛出这个异常。
-
ClassCastException: 当试图将一个对象强制转换为不是其实例的类型时抛出。 例如，你试图将一个
String对象强制转换为Integer对象，就会抛出这个异常。 - ArithmeticException: 当发生算术错误时抛出，例如除以零。
Checked Exception的例子：
- IOException: 处理输入输出操作时可能发生的异常，例如文件不存在、网络连接中断等。
- SQLException: 处理数据库操作时可能发生的异常，例如数据库连接失败、SQL语法错误等。
- ClassNotFoundException: 当试图加载一个不存在的类时抛出。
如何选择合适的异常类？
选择合适的异常类，其实就是选择最能准确描述问题的异常类。 如果Java提供的异常类已经能够满足你的需求，那就直接使用它们。 如果Java提供的异常类不够具体，你可以考虑自定义异常类。 自定义异常类通常继承自Exception或者RuntimeException。 继承自Exception的自定义异常类是Checked Exception，需要强制处理；继承自RuntimeException的自定义异常类是Unchecked Exception，不需要强制处理。 我通常会选择继承自RuntimeException，因为我觉得强制处理所有异常会增加代码的复杂度。 当然，这取决于具体的业务场景。 如果某个异常的发生概率很高，并且需要立即处理，那就应该选择Checked Exception。
异常处理的最佳实践是什么？
异常处理不仅仅是简单地捕获异常并打印日志。 好的异常处理应该能够帮助我们快速定位问题，并且尽可能地恢复程序的状态。 以下是一些异常处理的最佳实践：
- 不要捕获所有异常： 只捕获你能够处理的异常。 如果你无法处理某个异常，那就应该将它抛出，让上层调用者来处理。
- 不要忽略异常： 捕获异常之后，一定要做一些处理。 至少应该打印日志，方便我们排查问题。
-
使用
try-with-resources语句： 对于实现了AutoCloseable接口的资源，应该使用try-with-resources语句来自动关闭资源，避免资源泄露。 - 自定义异常类： 如果Java提供的异常类不够具体，可以考虑自定义异常类。
-
避免在
finally块中抛出异常： 如果在finally块中抛出异常，可能会覆盖之前的异常信息，导致我们无法定位到真正的问题。 - 记录足够的信息： 在打印异常日志时，应该记录足够的信息，例如异常发生的时间、线程、类名、方法名、参数等。 这样可以帮助我们快速定位问题。
什么时候应该抛出异常？
抛出异常的时机也很重要。 一般来说，当遇到无法处理的错误时，就应该抛出异常。 例如，当方法接收到不合法的参数时，或者当方法无法完成预期的功能时。 抛出异常可以通知调用者发生了错误，并且可以中断程序的执行，避免产生不可预料的后果。 但是，不要滥用异常。 异常处理的代价很高，会影响程序的性能。 对于一些可以预料的错误，可以使用返回值来表示。 例如，如果方法需要返回一个对象，但是该对象不存在，可以返回null，而不是抛出异常。
