为什么要处理异常，使用场景？

大家好，我是IT修真院深圳分院第6期学员，一枚正直善良的JAVA程序员。

今天给大家分享一下，修真院官网任务中用到的知识点，异常处理。

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.扩展思考

spring MVC 异常统一处理？

7.参考文献

1.知乎

2.https://blog.csdn.net/eson_15/article/details/51731567

8.更多讨论

1.大段try/catch到底能不能写？

A：如果try中的异常较统一且确定，可以统一处理，使代码可读性更好。

2.在方法名后抛出异常和在方法体中排除异常有什么区别？

A：如果方法体内抛出，方法名后也要抛出。

3.springmvc  ExceptionHandler是如何实现的？

A：原理不太懂，只能说controller中有对应的Exception抛出，并且springmvc ExceptionHandler有定义相应类型的话就可以自动捕获。

感谢大家观看

PPT：PPT

视频：视频

今天的分享就到这里啦，欢迎大家点赞、转发、留言、拍砖~

技能树.IT修真院

“我们相信人人都可以成为一个工程师，现在开始，找个师兄，带你入门，掌控自己学习的节奏，学习的路上不再迷茫”。

这里是技能树.IT修真院，成千上万的师兄在这里找到了自己的学习路线，学习透明化，成长可见化，师兄1对1免费指导。快来与我一起学习吧~

小礼物走一走，来简书关注我

赞赏支持

作者：blue

链接：

來源：简书

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。