发表于: 2018-04-06 22:23:20

1 553


今天完成的事情:

1.小课堂的内容。

1.背景介绍
在理想境界中,程序永远不会出现问题,用户输入的数据永远是正确的,逻辑没有任何问题 ,选择打开的文件也一定是存在的,内存永远是够用的……反正没有任何问题!但是一旦出现这些问题,如果处理不好,程序就不能正常运行了,用户就有可能再也不使用这个程序了。
2.知识剖析

对比一下我们就会发现,RuntimeException 是在程序中可以完全避免的,比如数组越界异常,只要我们在程序里作个判断,如果要访问的数组元素下标和数组的长度作一下比较就知道会不会越界,再比如空指针异常,如果在访问对象时判断一下对象的变量是否为空就可以了。

而非RuntimeException 则是程序无法避免的,比如IO异常,你的程序正在读一个文件,而这个文件所在磁盘出现了坏道,这就必然会引发IOException,这是不是靠编程高手编写完美的程序就可以法避免得了的,程序所能做的只有出现异常之后怎么处理的问题。
异常处理程序可以做的不仅仅是打印错误消息或停止程序。 它们可以执行错误恢复,提示用户做出决定,或者使用异常链将错误传播到更高级别的处理程序
3.常见问题
1.什么时候抛出,什么时候捕获?
2.在Controller里,大段的Try Catch 会有什么坏处?
4.解决方案
1.什么时候抛出,什么时候捕获。?

Java异常处理原则之一:延迟捕获


意思是,当异常发生时,不应立即捕获,而是应该考虑当前作用域是否有有能力处理这一异常的能力,如果没有,则应将该异常继续向上抛出,交由更上层的作用域来处理。


一个例子:

某方法String readFile(String filename),会去尝试读出指定文件的内容并返回,其使用FileInputStream来读取指定文件,而FileInputStream的构造方法会抛出FileNotFoundException,这是一个Checked Exception。

那么readFile方法是应该捕获这个异常,还是抛出这个异常呢?

很显然应该抛出。因为readFile这个方法可能会在不同的场景下,被不同的代码调用,在这些场景中,出现“文件未找到”的情况时的处理逻辑可能是不同的,例如某场景下要发出告警信息,另一场景下可能会尝试从另一个文件中读取,第三个场景下可能需要将错误信息提示给用户。在这种情况下,在readFile方法内的作用域中,是处理不了这个异常的,需要抛出,交由上层的,具备了处理这个异常的能力的作用域来处理。


2.在Controller里,大段的Try Catch 会有什么坏处?

1.try catch 的代价比较大。相对于判断返回值,抛出异常到捕获,需要更多的cpu指令和代码

2.Java的异常机制是由JVM控制的,业务逻辑复杂的情况下,会影响controller的执行效率

5.编码实战
6.扩展思考

1.SSM 异常统一处理

全局异常处理器

自定义异常:

controller


controller中抛出的异常如果全局异常处理中有定义,就可以被捕获,并返回设置的异常结果页面。


遇到的问题

1.异常的处理网上各种说法,好像每个公司的处理方式也各有不同,还不能确定controller中的异常到底如何处理才是最好的。


收获

1.对于异常捕获/抛出的时机,以及controller中try/catch的使用有了一些新的理解。


明天的计划

1.写完视频后台部分的接口。


进度:

复盘项目:求学大作战。

开始时间:2018.3.20日

计划demo时间:5.1号

延期风险:无

禅道地址:http://task.ptteng.com/zentao/project-task.html





返回列表 返回列表
评论

    分享到