为什么不必显式声明可能会在Java中抛出一些内置的异常？

Question

我注意到Integer.parseInt()你不必用try catch包围它，或者声明该方法可能抛出异常，尽管它“抛出”NumberFormatException

为什么我不必明确地捕获NumberFormatException或声明我的方法会抛出它？

Answer 1

因为那是“运行时”异常。

RuntimeExceptions 用于识别编程问题（一个优秀的程序员可以避免的），而

检查异常用于识别环境问题（无论您编程多好，服务器停机都无法避免）

您可以阅读有关them here

的更多信息

实际上three kinds of exceptions，只应处理其中一个（大部分时间）

Answer 2

         Throwable
         /      \
      Error    Exception
                /     \
           *checked*  RuntimeException
                            \
                         *unchecked*

有关已检查与未检查例外的详细说明，请参阅Thinking in Java。

有些人认为检查异常的想法是失败的实验。例如，Spring和Hibernate都使用未经检查的异常，并且经常在未经检查的版本中包装已检查的异常。

Answer 3

NumberFormatException扩展RuntimeException，您不必显式处理从RuntimeException继承的任何内容。

其他RuntimeExceptions类似于NullPointerException和IndexOutOfBoundsException。这些是程序员可以避免的事情，不得不尝试/捕获这些类型的异常会产生一些非常混乱的代码。

Answer 4

对工具包的答案进行了长时间的评论。

Checked异常是一个问题的原因是它们最终导致这样的代码：

try {
    Something that throws an exception
} catch (Exception e) {}

这是最糟糕的情况。首先，他们没有记录他们正在捕获异常。这种情况发生了很多，并且几乎被非常愚蠢的检查异常强制执行，例如Thread.sleep（）上的异常，它会抛出必须捕获的InterruptedException，但是99％的情况下，如果你有一个或者没有

在上面的案例中，如果抛出不止一个人，那么人们往往会抓住“异常”这一事实而更加复杂。这意味着即使抛出了一个严重的未经检查的异常，它也会被捕获并被忽略，因此几乎不可能找到问题。

不止一次，我参加的团队不得不花费大约一个月的时间来追踪以这种方式隐藏的漏洞。

当你补充人类必须负责任地实施它的事实时，这是一个很好的概念变得可怕。