【问题标题】:LocalDate.format(DateTimeFormatter formatter) does not declare "throws" in method signature [duplicate]LocalDate.format(DateTimeFormatter 格式化程序)未在方法签名中声明“抛出”[重复]
【发布时间】:2018-10-23 05:08:37
【问题描述】:

我正在浏览 LocalDate API 的 java 源代码,发现这些方法缺少 throws 声明。但是 javadoc 清楚地提到该方法可能会抛出 DateTimeException。以下是来自 Java 8 的 LocalDate API 的源代码。

/**
 * Formats this date using the specified formatter.
 * <p>
 * This date will be passed to the formatter to produce a string.
 *
 * @param formatter  the formatter to use, not null
 * @return the formatted date string, not null
 * @throws DateTimeException if an error occurs during printing
 */
@Override  // override for Javadoc and performance
public String format(DateTimeFormatter formatter) {
    Objects.requireNonNull(formatter, "formatter");
    return formatter.format(this);
}
  1. 这是否是声明抛出异常的方法的正确方法(我希望 throws 在方法签名中使客户端能够正确处理异常,但这并没有给客户端关于除非正在读取 javadoc,否则异常)?

如果我遗漏了什么以正确理解这一点,请告诉我?

【问题讨论】:

  • DateTimeExceptionRuntimeException,不需要抛出。总是喜欢未经检查的异常,以便您仅在需要时处理它
  • 对于未经检查的异常,最好不要在 throws 子句中声明它们,而是在 Javadoc/API 文档中记录它们。

标签: java java-8 exception-handling localdate


【解决方案1】:

DateTimeException 是未经检查的异常,因此不必声明为方法。

为什么LocalDate#format 声明它?因为它可以被它自己委托执行的方法抛出。在调用链之后,我们看到DateTimeFormatter.formatTo(TemporalAccessor, Appendable) 是执行实际工作的方法,它正在抛出异常;并且没有一个中间方法正在捕获/处理它。

public void formatTo(TemporalAccessor temporal, Appendable appendable) {
    ...
    try {
        ...
    } catch (IOException ex) {
        throw new DateTimeException(ex.getMessage(), ex);
    }
}

我相信这确实是一个很好的异常文档示例(记录应该预期的异常,无论是否检查,即使您没有明确地将它们抛出到相关方法中)

【讨论】:

  • 好的文档,当然。但是编写此代码的开发人员做出了糟糕的设计决定。我正在编写一个 API,其中除了字符串格式(json)的日期。如果调用者提供了一个无效的日期(例如,准确地说明它是哪个字段)而不是一个丑陋的通用 500 错误,我自然想给出一个信息性错误响应。这让我别无选择,只能捕获这个运行时异常。
  • @j5423951 我认为你所说的描述了预期的责任。如果您想自定义您的响应,您确实应该处理异常。如果你不这样做,唯一可以说的是你的代码崩溃了。日期时间 API 在其中没有任何作用。如果您谈论的是在解析入站 API 请求时发生的自动 JSON 绑定错误,那么这是 API 框架的问题,在日期时间 API 中仍然不是一个糟糕的设计。但我认为您可以自定义验证以在解析失败时添加所需的消息。
  • 一个人根本不需要捕获 RuntimeException,除非在处理线程/请求的代码中(即一个线程/请求死亡不应该杀死整个服务器)等。为简单的日期解析错误抛出 RuntimeException是荒谬的。他们期望我在解析之前验证字符串是不合理的,但我仍然想处理尝试解析字符串时发生的任何错误。
  • 这是一个有趣的观点,@j​​5423951。相反,我认为强制处理解析错误会很烦人,只是因为有人将其设为检查异常。但同样,如果它是一个运行时异常,背后有“不必处理它”的假设,那么这只会让系统崩溃。我认为我们的对话太多了。
  • 大多数开发人员不希望他们的系统因无法以合理且防弹的方式首先验证的错误日期字符串而崩溃。因此,“让系统崩溃”不是一种选择。所以,无论如何,它必须在某个地方被抓住。而且我认为系统不应该崩溃比必要的“更大”。大多数定制软件都有(或应该有)明确定义的方法来向调用系统返回适当的错误,并且一般的 500 错误(如果是基于 Web 的 API 或常规网站)是不适当的,除了系统中的错误。错误的输入会导致适当的错误。
猜你喜欢
  • 2019-01-06
  • 2021-04-20
  • 2021-03-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-05-06
  • 2016-05-07
  • 1970-01-01
相关资源
最近更新 更多