作者:✿✿ xxxflower. ✿✿
博客主页:xxxflower的博客
专栏:【Java项目】篇
语录:⭐每一个不曾起舞的日子,都是对生命的辜负。⭐
文章目录
1.认识异常
1.1异常
在Java中,将程序执行过程中发生的不正常行为称为异常。
1.算术异常
System.out.println(10 / 0);
2.数组越界异常
int[] arr = {1, 2, 3};
System.out.println(arr[100]);
3.空指针异常
int[] arr = null;
System.out.println(arr.length());
1.2异常的体系结构
Throwable:是异常体系的顶层类,其派生出两个重要的子类, Error 和 Exception
Error:指的是Java虚拟机无法解决的严重问题,比如:JVM的内部错误、资源耗尽等,典型代表:
StackOverflowError和OutOfMemoryError,一旦发生回力乏术。
Exception:异常产生后程序员可以通过代码进行处理,使程序继续执行。我们平时所说的异常就是Exception。
程序出问题都是bug
1.3异常的分类
异常可能在编译时发生,也可能在程序运行时发生,根据发生的时机不同,可以将异常分为:
- 编译时异常
在程序编译期间发生的异常,称为编译时异常,也称为受检查异常 - 运行时异常
在程序执行期间发生的异常,称为运行时异常,也称为非受检查异常
RunTimeException以及其子类对应的异常,都称为运行时异常。
编译时出现的语法性错误,不能称之为异常。
2.异常的处理
2.1防御时异常
错误在代码中是客观存在的. 因此我们要让程序出现问题的时候及时通知程序猿. 主要的方式:
- LBYL: Look Before You Leap. 在操作之前就做充分的检查. 即:事前防御型
boolean ret = false;
ret = 登陆游戏();
if (!ret) {
处理登陆游戏错误;
return;
} ret = 开始匹配();
if (!ret) {
处理匹配错误;
return;
} ret = 游戏确认();
if (!ret) {
处理游戏确认错误;
return;
} ret = 选择英雄();
if (!ret) {
处理选择英雄错误;
return;
} ret = 载入游戏画面();
if (!ret) {
处理载入游戏错误;
return;
}
缺陷:正常流程和错误处理流程代码混在一起, 代码整体显的比较混乱
- EAFP: It’s Easier to Ask Forgiveness than Permission. “事后获取原谅比事前获取许可更容易”. 也就是先操作, 遇到问题再处理. 即:事后认错型
try {
登陆游戏();
开始匹配();
游戏确认();
选择英雄();
载入游戏画面();
...
} catch (登陆游戏异常) {
处理登陆游戏异常;
} catch (开始匹配异常) {
处理开始匹配异常;
} catch (游戏确认异常) {
处理游戏确认异常;
} catch (选择英雄异常) {
处理选择英雄异常;
} catch (载入游戏画面异常) {
处理载入游戏画面异常;
}
优势:正常流程和错误流程是分离开的, 程序员更关注正常流程,代码更清晰,容易理解代码
所有的异常都是一个具体的类。
在Java中,异常处理主要的5个关键字:throw、try、catch、final、throws。
2.2异常的捕获
异常处理的意义在于发现异常后能否执行后续正常代码。
异常的捕获,也就是异常的具体处理方式,主要有两种:异常声明throws 以及 try-catch捕获处理。
2.2.1异常声明throws
处在方法声明时参数列表之后,当方法中抛出编译时异常,用户不想处理该异常,此时就可以借助throws将异常抛给方法的调用者来处理。即当前方法不处理异常,提醒方法的调用者处理异常。
注意事项:
- throws必须跟在方法的参数列表之后
- 声明的异常必须是 Exception 或者 Exception 的子类
- 方法内部如果抛出了多个异常,throws之后必须跟多个异常类型,之间用逗号隔开,如果抛出多个异常类型具有父子关系,直接声明父类即可。
- 调用声明抛出异常的方法时,调用者必须对该异常进行处理,或者继续使用throws抛出
将光标放在抛出异常方法上,alt + Insert 快速 处理:
2.2.2try-catch捕获并处理
throws对异常并没有真正处理,而是将异常报告给抛出异常方法的调用者,由调用者处理。如果真正要对异常进行处理,就需要try-catch。
还可以写成这样:
有小伙伴问:万一一次抛出两个异常或者多个异常,怎么办?
这个问题是错的!!!不会同时抛出两个及以上的异常!
此代码运行后可以打印出对应错误。但是靠运行去找异常不现实!
可以这样理解:此处发生了向上转型,发生动态绑定。相当于多态。
关于异常的处理方式
异常的种类有很多, 我们要根据不同的业务场景来决定.
- 对于比较严重的问题(例如和算钱相关的场景), 应该让程序直接崩溃, 防止造成更严重的后果
- 对于不太严重的问题(大多数场景), 可以记录错误日志, 并通过监控报警程序及时通知程序猿
- 对于可能会恢复的问题(和网络相关的场景), 可以尝试进行重试.
在我们当前的代码中采取的是经过简化的第二种方式. 我们记录的错误日志是出现异常的方法调用信息,
快速的让我们找到出现异常的位置. 以后在实际工作中我们会采取更完备的方式来记录异常信息.
【注意事项】
- try块内抛出异常位置之后的代码将不会被执行
- 如果抛出异常类型与catch时异常类型不匹配,即异常不会被成功捕获,也就不会被处理,继续往外抛,直到JVM收到后中断程序----异常是按照类型来捕获的
- try中可能会抛出多个不同的异常对象,则必须用多个catch来捕获----即多种异常,多次捕获。
- 如果异常之间具有父子关系,一定是子类异常在前catch,父类异常在后catch,否则语法错误。(exception是所有子类的父类。一般用于兜底!)
2.2.3finally
有些特定的代码,不论程序是否发生异常,都需要执行,比如程序中打开的资源:网络连接、数据库连接、IO流等,在程序正常或者异常退出时,必须要对资源进进行回收。另外,因为异常会引发程序的跳转,可能导致有些语句执行不到,finally就是用来解决这个问题的。格式如下:
问题:既然 finally 和 try-catch-finally 后的代码都会执行,那为什么还要有finally呢?
我们可以看到,finally中的代码是一定被执行了的。
注意:finally中的代码一定会执行的,一般在finally中进行一些资源清理的扫尾工作。
finally 执行的时机是在方法返回之前(try 或者 catch 中如果有 return 会在这个 return 之前执行 finally). 但是如果finally 中也存在 return 语句, 那么就会执行 finally 中的 return, 从而不会执行到 try 中原有的 return.
2.3异常的抛出
在Java中,可以借助throw关键字,抛出一个指定的异常对象,将错误信息告知给调用者。具体语法如下:
throw new XXXException("异常产生的原因");
但是此时,我们还没有有捕捉到异常,有两种方式
方法一:可以在main函数中捕捉异常
方法二:可以直接在函数中捕获
两种修改方式:
- 当即处理
- 声明异常
此时其实不算处理异常。只是声明。谁都不处理异常后就交给JVM了。
【注意事项】 - throw必须写在方法体内部
- 抛出的对象必须是Exception 或者 Exception 的子类对象
- 如果抛出的是 RunTimeException 或者 RunTimeException 的子类,则可以不用处理,直接交给JVM来处理
- 如果抛出的是编译时异常,用户必须处理,否则无法通过编译
- 异常一旦抛出,其后的代码就不会执行
如果本方法中没有合适的处理异常的方式, 就会沿着调用栈向上传递如果向上一直传递都没有合适的方法处理异常, 最终就会交给 JVM 处理, 程序就会异常终止(和我们最开始未使用 try catch 时是一样的).
【异常处理流程总结】
- 程序先执行 try 中的代码
- 如果 try 中的代码出现异常, 就会结束 try 中的代码, 看和 catch 中的异常类型是否匹配.
- 如果找到匹配的异常类型, 就会执行 catch 中的代码
- 如果没有找到匹配的异常类型, 就会将异常向上传递到上层调用者.
- 无论是否找到匹配的异常类型, finally 中的代码都会被执行到(在该方法结束之前执行).
- 如果上层调用者也没有处理的了异常, 就继续向上传递.
- 一直到 main 方法也没有合适的代码处理异常, 就会交给 JVM 来进行处理, 此时程序就会异常终止.
3.自定义异常类
有些情况会根据自己的业务场景抛出符合自己业务场景的异常,此时需要我们自定义异常。
我们可以基于已有的异常类进行扩展(继承), 创建和我们业务相关的异常类
具体方式:
- 自定义异常类,然后继承自Exception 或者 RunTimeException
- 实现一个带有String类型参数的构造方法,参数含义:出现异常的原因
注意事项
- 自定义异常通常会继承自 Exception 或者 RuntimeException
- 继承自 Exception 的异常默认是受查异常
- 继承自 RuntimeException 的异常默认是非受查异常.