当前位置: 首页 > 面试题库 >

Java异常为已检查的异常,但不需要在trycatch中引发

黄德明
2023-03-14
问题内容

我有这个片段。

public final class StackOverflow{
   class MyException extends Throwable{
   }
   private void a(){
       try{
       }catch(MyException | Exception e){
       }
   }
}
exception StackOverflow.MyException is never thrown in body of corresponding try statement

我知道Exception也在扩展Throwable,这也是一个检查异常,而MyException也在扩展Throwable,这也使得一个Checked异常!

我的问题是,为什么不要求在try catch中抛出异常,而MyException是异常?我认为两者都是检查异常,所以有什么区别?

很抱歉,问题很简单。


问题答案:

Java语言规范中对此进行了解释(粗体强调):

如果catch子句 可以捕获已 检查的异常类E1,并且不是trycatch子句相对应的块 可以抛出
作为E1的子类或超类的已检查的异常类,则不是编译时错误, 除非E1是Exception或父类。的Exception

我想这背后的理由是:MyException确实是一个检查异常。但是,未经检查的异常也会扩展Exception(从继承继承RuntimeException),因此在编译器进行的异常html" target="_blank">分析中排除了catch包含Exception类。



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

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

  • 我有以下两个示例,我不清楚java.lang.Exception是如何处理的:作为检查的或未检查的异常。 以下方法编译成功: 在这里,我认为java.lang.Exception是威胁java.lang.RuntimeException或java.lang.Error。不处理也可以声明扔。 如果我们没有使用异常,而是使用了检查异常(它是java.lang.Exception的子类),那么您必须在方

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

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

  • 因为Java编程语言不需要捕获方法或声明未检查异常(包括 RuntimeException、Error及其子类),程序员可能会试图编写只抛出未检查异常的代码,或使所有异常子类继承自RuntimeException。这两个快捷方式都允许程序员编写代码,而不必担心编译器错误,也不用担心声明或捕获任何异常。虽然这对于程序员似乎很方便,但它避开了捕获或者声明异常的需求,并且可能会导致其他人在使用您的类而产