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

在try块中捕获的非检查异常不是Java中的检查异常吗?

爱花蜂
2023-03-14
问题内容

有人告诉我,在Java中,可以在try块中捕获未检查的异常,但是如果捕获了它,就不称为已检查的异常吗?


问题答案:

未检查的异常是不需要在try-
catch块中捕获的异常。未检查的异常是RuntimeExceptionError类的子类。

已检查的异常是需要在try- catch块中捕获的异常。

可在Java语言规范的11.2节:编译时检查异常中找到检查和未检查异常的定义:

未检查的异常类是类RuntimeException及其子类,以及类Error及其子类。所有其他异常类都是检查的异常类。

仅仅因为未检查的异常被捕获在catch块中并不能使其成为已检查的异常-这仅意味着未检查的异常已被捕获并在catch块中进行了处理。

一个可能catch是未检查的异常,然后throw是新的已检查的异常,因此任何调用该方法的方法都可能发生未检查的异常,并强制调用该方法的方法处理某种异常。

例如,NumberFormatException当处理一些无法解析StringInteger.parseInt方法时可以抛出的a
是未经检查的异常,因此不需要捕获它。但是,调用该方法的方法可能希望其调用者正确处理此问题,因此它可能引发另一个被检查的异常(不是。的子类RuntimeException):

public int getIntegerFromInput(String s) throws BadInputException {
    int i = 0;
    try {
        i = Integer.parseInt(s);
    catch (NumberFormatException e) {
        throw new BadInputException();
    }

    return i;
}

在上面的示例中,- NumberFormatException被捕获在try-
catch块中,并且BadInputException引发了新的(旨在作为已检查的异常)。

getIntegerFromInput方法的任何调用者都将被强制捕获一个BadInputException,并被迫处理错误的输入。如果NumberFormatException不希望捕获和处理,则此方法的任何调用者都必须正确处理异常。

(还应注意,吃掉异常并做一些没有真正意义的事情不被认为是一种好习惯-处理可以执行有意义的异常处理的异常。)

从Java教程中:

  • 经验教训:例外
    • 捕获或指定需求 -讨论检查的异常。
    • 链式异常 -捕获异常并抛出新异常的做法,如上例所示。
    • 未经检查的例外情况-争议


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

  • 问题内容: 在Java中,引发 检查 异常(Exception或其子类型- IOException,InterruptedException等)的方法必须声明 throws 语句: 不声明语句的 方法不能 引发检查的异常。 但是在Java中使用安全方法捕获检查的异常仍然合法: 其实没有 有点可笑:编译器知道 e 不是检查的异常,因此可以将其重新抛出。事情甚至有些荒谬,此代码无法编译: 第一个片段是

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

  • 我的RMI服务器接口声明了一个方法foo(),该方法被声明为引发RemoteException和Exception,如下所示: 服务器实现为: 我的客户端在服务器上调用foo: 现在,当我运行客户端时,我得到: 从java类型的foo()中获取异常。rmi。异常异常:未声明的检查异常;嵌套的例外是:java。伊奥。InterruptedIOException:操作超时 Java文档是这样说的。rm

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

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