【问题标题】:Is there a need to catch exceptions that I've speciffied in throws clause?是否需要捕获我在 throws 子句中指定的异常?
【发布时间】:2015-07-13 17:22:01
【问题描述】:

是否需要捕获我在 throws 子句中指定的异常?反之亦然,是否需要指定捕获的异常?

public method() throws IOException, SQLException {
     ...
     try {
          ....
     }catch(IOException | SQLException ex) {
          ex.getMessage();
     }
}

【问题讨论】:

  • 上面的代码没有意义。该方法实际上永远不会抛出这些异常,因为您捕获了它们,但是您将强制调用方法捕获异常(永远不会抛出)或在整个流程中将它们声明为“可以抛出”。所以:要么抓住它们,要么扔掉它们。但是,不,如果你接住了它们,你就不应该扔球。
  • 没有。您要么在方法签名中抛出异常,要么捕获它们。你不应该两者都做。如果这样做,catch 将执行
  • 这基本上就是你和狗玩的游戏——假装你在扔球,然后抓住它,看到你的狗一无所获。

标签: java exception try-catch throws


【解决方案1】:

有两种例外情况:

选中和未选中。

This page 说:

Checked:是在编译时检查的异常

Unchecked 是编译时不检查的异常

            +-----------+
          | Throwable |
            +-----------+
             /         \
          /           \
      +-------+          +-----------+
      | Error |          | Exception |
      +-------+          +-----------+
    /  |  \            /     |    \
      \______/            \______/     \
                                   +------------------+
    unchecked       checked        | RuntimeException |
                                   +------------------+
                                    /   |    |      \
                                    \________________/

                                        unchecked

因此,如果可以合理地期望客户端从异常中恢复,则这是一条通用规则,请将其设为已检查异常。如果客户端无法从异常中恢复,请将其设为未经检查的异常

还有on this site,上面写着:

异常处理主要用于处理已检查的异常。如果 发生任何未经检查的异常,例如 NullPointerException,它 是程序员的错,他没有在之前进行检查 正在使用的代码。

【讨论】:

【解决方案2】:

catch 异常的概念是为了表明某些事情出错了。对用户和开发者来说。 捕获异常并写入日志以记录错误总是很好。越详细越好,更容易修复代码。 但是如果你像 sqlException 这样的特定异常,你可以跳过另一种可以抛出的异常。

【讨论】:

    【解决方案3】:

    你的方法不需要声明它会抛出这些异常,因为你在方法中捕获了它们。 throws 应该在可以从方法中抛出异常并且必须在调用树的上方进一步处理时使用。

    在此示例中,MyCheckedException 是一个异常,它可能会从您的方法中抛出,并且必须由调用方法处理,方法是让该方法捕获异常或声明它会抛出它。

    public method() throws MyCheckedException {
        ...
        try {
            ....
        } catch(IOException | SQLException ex) {
            ex.getMessage();
        }
    }
    

    如果异常是 RuntimeException 或扩展 RuntimeException,则无需声明它已被抛出(但这里存在更深层次的设计问题)。

    【讨论】:

      【解决方案4】:

      简短的回答是“不”。如果您在代码中捕获异常,那么您将不会抛出它们(如前面的评论所述),因此无需在 throws 子句中声明它们。相反,如果你想把它们扔给你的来电者,你不应该抓住它们。唯一的例外是您可能出于某种原因想要捕获异常并将其记录在此处,然后重新抛出它以处理堆栈的更远位置。

      【讨论】:

        【解决方案5】:
        • 你可以声明一个方法throws Exception如果你想要 调用方法来捕获异常。
        • 如果您希望相同的方法处理异常,那么您必须捕获它。
        • 您应该捕获将方法声明为throws 的异常

        【讨论】:

          【解决方案6】:

          您可能处于需要捕获任何异常以用于日志记录或实际业务逻辑的情况:如果 this 操作失败,则使用 this 操作作为备份。

          在您的情况下,您正在接受异常,因为似乎没有对 ex.getMessage() 返回的内容进行任何处理,不建议这样做。

          【讨论】:

            【解决方案7】:

            没有明确需要捕获签名中指定的异常。

            理想情况下,答案取决于,如果你想将异常传播给调用者,那么不要捕获异常。让调用者知道异常并决定接下来要做什么,例如显示消息、恢复操作、清理等。最好不要捕获异常

            【讨论】:

            • 好的,当我在它抛出的方法中本地捕获异常时(没有指定它们),那么当我调用该方法时,我不必捕获它们。另一个问题是为什么 API 中的方法只指定异常而不在本地捕获它们,以便用户可以在不处理异常的情况下调用它们?这是出于性能原因吗?
            • 一点也不,性能不成画面。在方法中捕获异常并没有什么坏处,但正如我所说,将异常传播给调用者总是更好。来电者应该知道,为什么它失败了。如果您使用异常,调用者不知道调用者内部发生了什么,除非您在返回值上写一些 hceck。这不是强制性的,但它的良好做法。
            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2013-07-17
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多