约书亚·布洛赫(Joshua Bloch)在《有效的Java》中说
将检查的异常用于可恢复的条件,将运行时异常用于编程错误(第二版中的项目58)
让我们看看我是否正确理解了这一点。
这是我对检查异常的理解:
try{ String userInput = //read in user input Long id = Long.parseLong(userInput); }catch(NumberFormatException e){ id = 0; //recover the situation by setting the id to 0 }
1.以上是否被视为经过检查的异常?
这是我对未经检查的异常的理解:
try{ File file = new File("my/file/path"); FileInputStream fis = new FileInputStream(file); }catch(FileNotFoundException e){ //3. What should I do here? //Should I "throw new FileNotFoundException("File not found");"? //Should I log? //Or should I System.exit(0);? }
4.现在,上面的代码难道不是一个检查过的异常吗?我可以尝试恢复这种情况吗?我可以吗?(注意:我的第三个问题在catch上面)
try{ String filePath = //read in from user input file path File file = new File(filePath); FileInputStream fis = new FileInputStream(file); }catch(FileNotFoundException e){ //Kindly prompt the user an error message //Somehow ask the user to re-enter the file path. }
5.人们为什么这样做?
public void someMethod throws Exception{ }
他们为什么让异常冒出来?处理错误不是更好吗?为什么冒泡?
许多人说,根本不应该使用检查的异常(即应明确捕获或重新抛出的异常)。例如,它们在C#中已被淘汰,并且大多数语言都没有它们。因此,您始终可以抛出RuntimeException(未经检查的异常)的子类
但是,我认为检查异常很有用-当您要强制API用户考虑如何处理特殊情况(如果可恢复)时,可以使用它们。只是在Java平台中过度使用了检查异常,这使人们讨厌它们。
这是我对该主题的扩展看法。
至于特定的问题:
是否NumberFormatException考虑过检查异常? 编号NumberFormatException未选中(=是的子类RuntimeException)。为什么?我不知道。(但应该有一个方法isValidInteger(..))
NumberFormatException
RuntimeException
isValidInteger(..)
是RuntimeException未经检查的异常吗? 对,就是这样。
我应该在这里做什么? 这取决于此代码在哪里以及您想要发生什么。如果在UI层中-捕获并显示警告;如果它在服务层中-根本不要抓住它-让它冒泡。只是不要吞下异常。如果在大多数情况下发生异常,则应选择以下一种:
记录并返回 重新抛出它(声明它被方法抛出) 通过在构造函数中传递当前异常来构造新异常
现在,上面的代码难道不是一个检查异常吗?我可以尝试恢复这种情况吗?我可以吗? 本来可以的。但是也没有什么可以阻止您捕获未经检查的异常
人们为什么Exception在throws子句中添加类? 大多数情况下,是因为人们懒于考虑要捕获什么和重新抛出什么。投掷Exception是一种不良习惯,应避免。
las,没有一个单一的规则可让您确定何时捕获,何时重新抛出,何时使用已检查的异常以及何时使用未检查的异常。我同意这会引起很多混乱和很多错误代码。Bloch陈述了一般原则(您引用了其中一部分)。通常的原则是将异常抛出到可以处理它的层。
某项是否为“受检查的异常”与您是否捕获它或在catch块中执行的操作无关。这是异常类的属性。凡是是的一个子类Exception ,除了对RuntimeException和它的子类是经过检查的异常。
Java编译器迫使您要么捕获检查的异常,要么在方法签名中声明它们。本来可以提高程序安全性,但是大多数人似乎认为这样做不值得产生设计上的问题。
他们为什么让异常冒出来?处理错误越早越好吗?为什么冒泡?
因为这是整个点异常。没有这种可能性,您将不需要例外。它们使您能够在选择的级别上处理错误,而不是强迫您使用错误最初发生的低级方法进行处理。