当前位置: 首页 > 知识库问答 >
问题:

Java检查的与未检查的异常--仅从代码中分辨?

冯亮
2023-03-14

是否可以通过查看代码来判断一个异常类是选中的还是未选中的?我一直认为,如果它扩展了Exception,那么它就会被选中,但是RuntimeException扩展了Exception,那么它就会被取消选中。RuntimeException可能是唯一一个改变了经验法则的类,如果不扩展RuntimeException的话,其他未经检查的异常也必须扩展Throwable。但是,我看不出RuntimeException与Exception有什么不同。我想知道这种区别是否是在解释器本身内部定义的?

共有1个答案

於宏大
2023-03-14

是否可以通过查看代码来判断一个异常类是选中的还是未选中的?

是的。如果您知道JLS(11.1.1)中指定的规则...并且您还可以看到异常的超类的代码(这样您就可以检查层次结构)。

规则是“检查”例外情况,但以下情况除外:

不,它是Java语言规范的。实际上,JVM对检查的和未检查的异常的处理是一样的。所有检查是否正确处理已检查的异常的工作都是由Java编译器完成的。

但是,我仍然不理解RuntimeException扩展Exception而不是Throwable的推理。考虑到RuntimeException中没有重写Exception中定义的行为,这种设计选择似乎是矛盾的。

事情就是这样。而且,我看不出有什么逻辑上的矛盾。

 类似资料:
  • 问题内容: 我在理解Java 和异常之间的区别时遇到了一些问题。 首先,异常应该在编译时寻找异常。在不同来源中提供的示例引用了数据库连接性,其中一些是文件处理,而异常应该是在程序员方面寻找错误,例如索引超出数组范围等。 不应该反过来吗?我的意思是,数据库连接是在运行时完成的,对吧?文件处理也是如此。您没有在编译时打开文件句柄,那么为什么在编译时会寻找一个可能的错误呢?另一方面,超出数组范围的索引已

  • 问题内容: 约书亚·布洛赫(Joshua Bloch)在《有效的Java》中说 将检查的异常用于可恢复的条件,将运行时异常用于编程错误(第二版中的项目58) 让我们看看我是否正确理解了这一点。 这是我对检查异常的理解: 1.以上是否被视为经过检查的异常? RuntimeException是未经检查的异常吗? 这是我对未经检查的异常的理解: 4.现在,上面的代码难道不是一个检查过的异常吗?我可以尝试

  • 问题内容: 我一直在阅读有关未解决问题和已解决问题的信息,没有一个在线资源真正了解它们之间的区别以及何时使用两者。 据我了解,它们都在运行时抛出,它们都表示超出逻辑预期范围的程序状态,但是必须显式捕获已检查的异常,而未检查的异常则不能。 我的问题是,假设出于参数考虑,我有一个将两个数字相除的方法 以及需要在某处划分的方法 谁负责检查分母为零的情况,应该检查还是取消检查异常(忽略Java的内置div

  • 问题内容: 我在一个带有旧服务层的项目上工作,如果请求的记录不存在,或者由于调用者未得到授权而无法访问,则在很多地方返回null。我说的是ID要求的特定记录。例如,类似: 最近,我一直在努力更改此API,或者用引发异常的新API进行补充。随之而来的是关于检查与未检查的异常的争论。 从JPA / Hibernate等所有设计师的笔记中,我建议未检查的异常可能是最合适的。我的观点是,不能合理地期望AP

  • 问题内容: 据我了解,如果不逐一查找API文档,就无法找出方法抛出的异常。 由于这是没有选择的,因此我想撤消研究,并询问您在处理时遇到的最常见的Exception和RuntimeException: 铸件 数组 向量,ArrayList,HashMap等 IO(文件类,流,过滤器…) 对象序列化 线程(wait(),sleep()等) 或任何其他被视为“基本Java”的内容 我意识到这可能是主观的

  • 问题内容: 我在Java中有这个工厂方法: 我想将两个已检查的异常转换为未检查的异常。最好的方法是什么? 我是否应该仅捕获异常并使用捕获的异常作为内部异常抛出新的RuntimeException? 有没有更好的方法可以做到这一点?或者我应该首先尝试这样做吗? 编辑: 只是为了澄清。这些异常将是致命的,因为配置文件实质上是程序的运行,所有异常都将在程序的顶层捕获并记录。 我的目的是避免不必要的引发异