异常处理与日志
内存、断言、反射、异常
是否能很好的处理异常,有好的解决方案、demo和企业级的项目的区别
不同的return就是在处理异常,但是
合理的捕获就不会产生异常,走try catch finally,只是抛出异常信息,导致程序的中止
思考完的版本:java程序发生异常,java虚拟机jvm会帮助程序自动生成实例化异常对象,这时候看程序是否有catch,如果有捕获异常继续执行,可能有多个catch捕获不同类型的异常,最后看是否有finally(程序中是否已经处理所有异常)存在则继续执行,否则会交给jvm处理,会导致程序终止
try catch finally都可能产生异常但是会被捕获,但是我们没有或者不想处理,可以throw抛出异常
代码块中出现了多个异常,怎么样才能捕获
1.区分多种异常捕获的处理是否是一种异常,做相同的处理
共同的父类的异常,后续的操作也一致,可以一起的抛出
多个catch块 与 处理的异常一样
否则只能多个catch分别处理
其他的系统的调用 统一使用throw exception和error的父类
多种异常有共同的父类的异常,可以用父类捕获子类,多个catch与*(共同的后续操作)
error的异常程序不能处理 throwble
用旅行的案例受检和非受检的异常,个人可控的非受检异常
总体来讲java异常体系可以分为(“大异常,所有异常”):error(不可抗力,无能为力的灾难性的)向上抛出到jvm程序终止,exception(灾害,可以自救的),灾后的救灾分为RuntimeException(余震、缺衣少食等可预见的可以处理的异常)和checked(房屋倒塌、人员罹难等想处理但是无能为力的)
error虚拟机异常必须重启,堆栈溢出,内存溢出 必须做其他处理、重启的操作的
针对java编译器受检非受检io,引用类,类找不到等为受检类的异常
非受检的异常,可预测的数组越界,字符串,集合的越界,提前的检测预测,尽可能的不走到这个异常处理的流程中,性能回差,应提前处理
2异常处理设计实践
1.强大优雅但是不是随处的使用,能遇见的直接提前做处理不要抛出
java的异常主要是针对不稳定的代码,不要将稳定的代码也放进去,过多的代码抛出不一样的异常也会导致异常的向上抛出
使用条件判断的性能更强
2.至少添加发生异常的相关信息再向上抛出
3.自己能处理的异常一定要自己处理不要给调要的人去处理
不要在finaly块中使用return
finally如果放开return 则程序的结果就是 finally try中的返回值就被忽略了
foreach遍历集合的异常
抛出异常造成资源浪费,先整理异常的信息,在合适的时候再抛出异常
提升系统的运营能力,快速的找到问题,监控一些数值。
记录日志的方式和方法也到得当
敏感操作信息联机存书6个月,配合调查,发生官司和纠纷没有证据
配置
都打开会jar包冲突 只能出现一种日志配置,会都不记录日志,会冲突,推瘫痪
默认
使用+会消耗性能
将对象转化成string,禁止使用json工具
分包策略
日志线程的模型 异步的速度快
日志输出
错误码
没有很好的错误码,对于错误的对应会增加难度
错误码规约
controller捕获异常
是要霉层单独记录的