Java API设计:解析半数字字符串的方法的NumberFormatException?

MB.*_*MB. 12 java api api-design

我正在创建一个包含一些解析字符串日期和时间的方法的库.当字符串参数不可解析时,我很难确定这些方法应该抛出的异常.我正在考虑几种选择:

1. java.lang.IllegalArgumentException - 一个无效的字符串显然是一个非法的论点,但对我来说,IllegalArgumentException通常意味着编程错误,并且很少想要try catch为一个字符串做一个明确的.我认为字符串解析通常用于外部输入,更像是一种值得特殊处理的特殊情况.例如,如果您有一大块代码解析用户输入并对其执行其他操作,您可能希望将该代码包装在try catch块中,以便您可以处理包含无效字符串的用户输入的情况.但是捕获IllegalArgumentException对于查明无效的用户输入并不是很好,因为很可能在代码中有多个地方可以抛出它(而不仅仅是用户输入的解析).

2. java.lang.NumberFormatException - 它Integer.parseInt(String)和其他类似的解析方法一起被抛出java.lang.因此,大多数Java开发人员都熟悉,当您尝试解析可能有效或无效的字符串(例如用户输入)时,它会被捕获.但它的名字中有"数字",所以我不确定它是否真的适合日期和时间这些在某种意义上是数字的东西,但在我看来在概念上是不同的.如果只是它被称为"FormatException"...

3. java.text.ParseException - 不是真正的选择,因为它已被检查.我想要不加控制.

4.自定义异常 -这得到周围人的缺点IllegalArgumentExceptionNumberFormatException,故能扩大IllegalArgumentException了.但我不认为向库中添加异常是个好主意,除非真的需要它们.引用Josh Bloch的话说,"如果有疑问,请把它留下来".(另外,在我的例子中,对于解析日期和时间的包,很难命名这样的异常:"DateFormatException","TimeFormatException","CalendricalFormatException"(如JSR 310) - 当应用于方法时,似乎没有一个对我来说是理想的解析日期,时间,日期时间等.我认为如果它们都只用于识别不可解析的字符串,那么在单个包中创建多个异常会很愚蠢.)

那么您认为哪种选择最有意义?

注意:我有充分的理由不想使用java.util.Date或Joda Time,或JSR 310,因此无需提出建议.另外我认为如果这个问题保持相当普遍会很好,因为这一定是其他设计API的人一直在努力解决的问题.日期和时间也可以是IP地址,URL或具有需要解析的字符串格式的任何其他类型的信息.

其他图书馆设定的先例

我发现的几个例子:

java.sql.Timestamp.valueOf(String) throws IllegalArgumentException

java.util.Date.parse(String) throws IllegalArgumentException (已弃用的方法,并且未声明异常,但您可以在源代码中看到它)

java.util.UUID.fromString(String) throws IllegalArgumentException

org.apache.axis.types.Time(String) throws NumberFormatException (也是Apache Axis中的Day类)

org.apache.tools.ant.util.DeweyDecimal(String) throws NumberFormatException

com.google.gdata.data.DateTime.parseDateTime(String) throws NumberFormatException

java.lang.Package.isCompatibleWith(String versionString) throws NumberFormatException (在Java 7中,这需要带点的字符串版本号 - 有点像某个意义上的日期或时间)

我确信有很多软件包使用自定义异常,因此我怀疑提供这些例子有很多意义.

小智 0

对于这个问题,这是一个品味问题。在我看来,我不会抛出异常,而是会处理该异常。原因是如果输入错误,用户将无法在异常处理程序中执行任何操作。因此,可以通过检查返回码轻松处理这些类型的错误。异常很严重并且不会带来额外的价值。

  • 我同意异常很严重,但我强烈不同意在返回值中包含错误。这需要臃肿的响应对象或返回对象,这两者都会使简单的 API 无法使用。 (2认同)