面试时java文件读取，什么时候用throws IOException,什么时候用

功能需要抛出异常中断try catch，不需要就往上层抛，谁调用谁处理

顶额

https://blog.csdn.net/sdr_zd/article/details/75675004 【 在 PMS 的大作中提到: 】 : 面试时java文件读取，什么时候用throws IOException,什么时候用try-catch (IOException e)啊？ : 无论是写java代码，还是被技术问题，都遇到过这个问题

首先用try-with-resources语句。这样不管有没有异常都会保证关闭文件。 然后，一直往上抛，除非有一层能够给出“如果发生异常，做xxx就能恢复”否则就不要catch。

基本赞同暖神。 我的原则是：以不使用异常为基准的，一直向外层抛，除非哪里有明确的处理。常见的处理方式有直接挂掉、重试、错误恢复等。 补充一句，，，如果可能，尽量以可读性为第一标准使用异常。比如文件可能不存在的情况，工程上更好的风格是主动检查文件是否存在，不存在就抛异常，存在再open；极其不推荐不管存不存在直接open——尽管调用open时内部会检查文件是否存在。

一般try语句应该是自定义异常来抓取错误的吧，像正常的异常最好抛出去，比如spring中的事务管理，就是通过检测异常来回滚的，一旦try了，事务回滚就失效了 【 在 FromSixToTen 的大作中提到: 】 : https://blog.csdn.net/sdr_zd/article/details/75675004

这样有个问题，就是所谓的“time of check to time of use (TOCTTOU)”。 https://en.m.wikipedia.org/wiki/Time_of_check_to_time_of_use 当程序刚刚判断文件存在，还没来得及打开的时候，文件就可能已经被删除了，更危险的是恶意的用户可能会把文件的内容换成别的，造成安全漏洞。所以，有时候必须直接打开，然后判断成功了没有，是以什么原因没有成功。 【 在 forienlauo 的大作中提到: 】 : 基本赞同暖神。 : 我的原则是：以不使用异常为基准的，一直向外层抛，除非哪里有明确的处理。常见的处理方式有直接挂掉、重试、错误恢复等。 :

严谨如暖神，，，我收敛一下我的观点，“在安全性要求不高的工程领域”，这种情况下只需要考虑非恶意攻击的badcase（比如系统管理员误删文件，文件系统bug等），上层会做简单的容错处理。 举个例子，YARN执行Container的时候，如果能登录到NodeManager上，想恶意攻击太容易了。防范这种恶意攻击的方式不是细化各种异常检查，而是通过有效的权限认证防止非法用户登录到NodeManager。 【 在 nuanyangyang 的大作中提到: 】 : 这样有个问题，就是所谓的“time of check to time of use (TOCTTOU)”。 : https://en.m.wikipedia.org/wiki/Time_of_check_to_time_of_use : 当程序刚刚判断文件存在，还没来得及打开的时候，文件就可能已经被删除了，更危险的是恶意的用户可能会把文件的内容换成别的，造成安全漏洞。所以，有时候必须直接打开，然后判断成功了没有，是以什么原因没有成功。 : ...................

【 在 justlikeu 的大作中提到: 】 : 功能需要抛出异常中断try catch，不需要就往上层抛，谁调用谁处理 O(∩_∩)O哈哈~明白了