Дизайн Java API: NumberFormatException для метода, анализирующего получисловую строку?

Я создаю библиотеку, которая содержит несколько методов для синтаксического анализа даты и времени строки. Мне сложно решить, какое исключение должны вызывать эти методы, если строковый аргумент не поддается синтаксическому анализу. Рассматриваю несколько вариантов:

1. java.lang.IllegalArgumentException - недопустимая строка явно является недопустимым аргументом, но для меня IllegalArgumentException обычно означает программную ошибку, и редко нужно делать явное попробуйте catch для одного. Я думаю, что синтаксический анализ строк часто используется для внешнего ввода и является более частным случаем, заслуживающим особого внимания. Если, скажем, у вас есть большой блок кода, который анализирует ввод пользователя и делает с ним что-то еще, вы можете заключить этот код в блок try catch, чтобы вы могли обработать случай ввода пользователя, содержащего недопустимую строку. Но перехват IllegalArgumentException не годится для точного определения недопустимого ввода пользователя, потому что, скорее всего, есть d может быть несколько мест в вашем коде, из которых он может быть брошен (не только при синтаксическом анализе, вводимом пользователем).

2. java.lang.NumberFormatException - это вызвано Integer.parseInt (String) и другими подобными методами синтаксического анализа в java.lang . Таким образом, большинство разработчиков Java знакомы с тем, что это исключение, которое можно поймать, когда вы пытаетесь проанализировать строку, которая может быть или не быть действительной (например, ввод пользователя). Но в его названии есть «Число», поэтому я не уверен, что он действительно подходит для таких вещей, как дата и время, которые в определенном смысле являются числовыми, но концептуально отличаются в моем понимании. Если бы только это называлось "FormatException" ...

3. java.text.ParseException - не совсем вариант, потому что он проверен. Я хочу снять этот флажок.

4. Пользовательское исключение - это позволяет избежать недостатков IllegalArgumentException и NumberFormatException , а также может расширить IllegalArgumentException . Но я не думаю, что добавлять исключения в библиотеку, если они действительно не нужны. Цитируя Джоша Блоха, «Если есть сомнения, оставьте это» . (Кроме того, в моем случае для пакета, который анализирует дату и время, довольно сложно назвать такое исключение: «DateFormatException», «TimeFormatException», «CalendricalFormatException» (например, JSR 310) - ни один из них не кажется мне идеальным в применении к методам. которые анализируют даты, время, дату и т. д. И я думаю, что было бы глупо создавать несколько исключений в одном пакете, если бы все они использовались только для идентификации неразборчивых строк.)

Итак, какой вариант, по вашему мнению, имеет наибольший смысл?

NB Для меня есть веские причины чтобы не использовать java.util.Date, Joda Time или JSR 310, поэтому не нужно их предлагать. Кроме того, я думаю, было бы хорошо, если бы этот вопрос оставался достаточно общим, поскольку это, должно быть, проблема, с которой боролись другие люди, разрабатывающие API. Датой и временем могут быть IP-адреса, URL-адреса или любая другая информация, имеющая строковые форматы, требующие синтаксического анализа.

Прецеденты, установленные другими библиотеками

Я нашел лишь несколько примеров:

java .sql.Timestamp.valueOf (String) вызывает исключение IllegalArgumentException

java.util.Date.