【发布时间】:2009-02-09 16:46:28
【问题描述】:
我注意到 Integer.parseInt() 不必用 try catch 包围它或声明该方法可能会抛出异常,尽管事实上它“抛出”了 NumberFormatException。
为什么我不必显式捕获 NumberFormatException 或声明我的方法抛出了它?
【问题讨论】:
我注意到 Integer.parseInt() 不必用 try catch 包围它或声明该方法可能会抛出异常,尽管事实上它“抛出”了 NumberFormatException。
为什么我不必显式捕获 NumberFormatException 或声明我的方法抛出了它?
【问题讨论】:
因为这是一个“运行时”异常。
RuntimeExceptions 用于识别编程问题(优秀的程序员可以避免),而
已检查异常是为了识别环境问题(无论你编程多么好,都无法避免,例如服务器宕机)
你可以阅读更多关于them here的信息
实际上有three kinds of exceptions,应该只处理其中一个(大多数时候)
【讨论】:
RuntimeExceptions,并且您可以通过在调用方法之前进行额外检查来避免检查异常。
NumberFormatException 是您通常应该捕获的。捕捉NumberFormatException 比尝试在将String 转换为数字之前自己检查它的格式要好,因为那样你可能仍然得到一个NumberFormatException,现在你不是捕捉。
IOException 是许多 API 到处乱扔的。这可能是我在其他人的代码中看到的最多捕获的异常,也是我在其他代码中看到的最多捕获的异常。在很多地方,你不得不捕获IOException 或其子类,在某些使用抛出它的 API 的上下文中,它永远不会被抛出。
IOException 再次,但这第三种情况与#2相反。未找到文件异常是您通常期望偶尔发生的异常,具体取决于用户的文件系统。但是,尽管是已检查异常,但从技术上讲,您可以在访问文件之前检查文件是否存在,这样做是一个非常简单的 1-liner。比检查String 的数字格式要容易得多。
File.exists 使用情况下,但这很笨拙)。
Throwable
/ \
Error Exception
/ \
*checked* RuntimeException
\
*unchecked*
请参阅 Thinking in Java 以获得有关已检查与未检查异常的详细说明。
有些人认为检查异常的想法是一个失败的实验。例如,Spring 和 Hibernate 都使用未检查的异常,并且经常将已检查的异常包装在未检查的版本中。
【讨论】:
NumberFormatException 扩展了 RuntimeException,您不必显式处理继承自 RuntimeException 的任何内容。
其他 RuntimeExceptions 是 NullPointerException 和 IndexOutOfBoundsException。这些是程序员可以避免的事情,并且必须尝试/捕获这些类型的异常会产生一些非常混乱的代码。
【讨论】:
只是对工具包答案的长评论。
Checked 异常成为问题的原因是它们最终会导致如下代码:
try {
Something that throws an exception
} catch (Exception e) {}
这是最坏的情况。首先,他们没有记录他们正在捕获异常。这种情况经常发生,并且几乎是由非常愚蠢的检查异常(例如 Thread.sleep() 上的异常)强制执行的,它会抛出必须捕获的 InterruptedException,但 99% 的时间你不在乎是否有一个.
在上述情况下,如果抛出多个异常,人们往往只会捕获“异常”,这使情况更加复杂。这意味着即使抛出了一个严重的未经检查的异常,它也会被捕获并忽略,从而几乎不可能找到问题。
我曾不止一次参与过不得不花费大约一个人月的时间来试图追踪以这种方式隐藏的错误的团队。
这是一个很好的概念,但当你加上人类是必须负责任地实施它的人这一事实时,它就变得可怕了。
【讨论】: