约书亚·布洛赫(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(..)
)
是RuntimeException
未经检查的异常吗?
对,就是这样。
我应该在这里做什么?
这取决于此代码在哪里以及您想要发生什么。如果在UI层中-捕获并显示警告;如果它在服务层中-根本不要抓住它-让它冒泡。只是不要吞下异常。如果在大多数情况下发生异常,则应选择以下一种:
记录并返回
重新抛出它(声明它被方法抛出)
通过在构造函数中传递当前异常来构造新异常
现在,上面的代码难道不是一个检查异常吗?我可以尝试恢复这种情况吗?我可以吗?
本来可以的。但是也没有什么可以阻止您捕获未经检查的异常
人们为什么Exception在throws子句中添加类?
大多数情况下,是因为人们懒于考虑要捕获什么和重新抛出什么。投掷Exception是一种不良习惯,应避免。
las,没有一个单一的规则可让您确定何时捕获,何时重新抛出,何时使用已检查的异常以及何时使用未检查的异常。我同意这会引起很多混乱和很多错误代码。Bloch陈述了一般原则(您引用了其中一部分)。通常的原则是将异常抛出到可以处理它的层。
问题内容: 我在理解Java 和异常之间的区别时遇到了一些问题。 首先,异常应该在编译时寻找异常。在不同来源中提供的示例引用了数据库连接性,其中一些是文件处理,而异常应该是在程序员方面寻找错误,例如索引超出数组范围等。 不应该反过来吗?我的意思是,数据库连接是在运行时完成的,对吧?文件处理也是如此。您没有在编译时打开文件句柄,那么为什么在编译时会寻找一个可能的错误呢?另一方面,超出数组范围的索引已
问题内容: 我一直在阅读有关未解决问题和已解决问题的信息,没有一个在线资源真正了解它们之间的区别以及何时使用两者。 据我了解,它们都在运行时抛出,它们都表示超出逻辑预期范围的程序状态,但是必须显式捕获已检查的异常,而未检查的异常则不能。 我的问题是,假设出于参数考虑,我有一个将两个数字相除的方法 以及需要在某处划分的方法 谁负责检查分母为零的情况,应该检查还是取消检查异常(忽略Java的内置div
问题内容: 我在一个带有旧服务层的项目上工作,如果请求的记录不存在,或者由于调用者未得到授权而无法访问,则在很多地方返回null。我说的是ID要求的特定记录。例如,类似: 最近,我一直在努力更改此API,或者用引发异常的新API进行补充。随之而来的是关于检查与未检查的异常的争论。 从JPA / Hibernate等所有设计师的笔记中,我建议未检查的异常可能是最合适的。我的观点是,不能合理地期望AP
是否可以通过查看代码来判断一个异常类是选中的还是未选中的?我一直认为,如果它扩展了Exception,那么它就会被选中,但是RuntimeException扩展了Exception,那么它就会被取消选中。RuntimeException可能是唯一一个改变了经验法则的类,如果不扩展RuntimeException的话,其他未经检查的异常也必须扩展Throwable。但是,我看不出RuntimeExc
本文向大家介绍Java中检查和未检查异常之间的区别,包括了Java中检查和未检查异常之间的区别的使用技巧和注意事项,需要的朋友参考一下 在本文中,我们将了解Java中已检查和未检查的异常之间的区别。 检查异常 它们在编译时发生。 编译器检查已检查的异常。 这些异常可以在编译时进行处理。 它是异常类的子类。 JVM要求捕获并处理异常。 已检查异常的示例-“找不到文件异常” 未检查的异常 这些异常在运
问题内容: 阅读本书中的 Exception时,我发现了以下语句: 被检查的异常由编译器在编译时检查。 和 编译器不会在编译时检查未经检查的异常。 因此,如果我们也可以说或 位于Checked Exceptions类树之下。如何将java编译器知道 会有 一个例外,没有对 其中 可能 仍然 代码为我的理解里面。 另外,强制捕获Checked异常而不是Unchecked意味着什么呢? 问题答案: J