如何理解java中的checked 和unchecked异常?

如何理解java中的checked 和unchecked异常?

回答:

许多人说根本不应该使用检查的异常(即应明确捕获或重新抛出的异常)。例如,它们已在C#中被淘汰,并且大多数语言都没有它们。因此,你始终可以抛出RuntimeException(未经检查的异常)的子类

但是,我认为检查异常非常有用-当你要强制API用户考虑如何处理特殊情况(如果可恢复)时,可以使用它们。只是在Java平台中过度使用了检查异常,这使人们讨厌它们。

至于特定的问题:

  1. 是否NumberFormatException考虑过检查异常?

    编号NumberFormatException未选中(=是的子类RuntimeException)。为什么?我不知道。(但应该有一个方法isValidInteger(..)

  2. RuntimeException未经检查的异常吗?

    对,就是这样。

  3. 我该怎么办?

    这取决于该代码在哪里以及你想要发生什么。如果它在UI层中-捕获并显示警告;如果它在服务层中-根本不要抓住它-让它冒泡。只是不要吞下异常。如果在大多数情况下发生异常,则应选择以下一种:

  4. 记录并返回

  5. 重新抛出它(声明它被方法抛出)
  6. 通过在构造函数中传递当前异常来构造新异常

  7. 现在,上面的代码难道不是一个检查异常吗?我可以尝试恢复这种情况吗?我可以吗?

    可能是这样。但是也没有什么可以阻止你捕获未经检查的异常

  8. 人们为什么Exceptionthrows子句中添加类?

    大多数情况下,是因为人们懒于考虑要捕获什么和重新抛出什么。投掷Exception是一种不良习惯,应避免。

las,没有一个单一的规则可以让你确定何时捕获,何时重新抛出,何时使用已检查的异常以及何时使用未检查的异常。我同意这会引起很多混乱和很多错误的代码。Bloch陈述了一般原则(你引用了其中一部分)。通常的原则是将异常抛出到可以处理它的层。

以上是 如何理解java中的checked 和unchecked异常? 的全部内容, 来源链接: utcz.com/qa/408833.html

回到顶部