Add non-throwing LocalDate(Time) construction & parsing

[fluidsonic]

There should be null-returning variants for creating LocalDate(Time) instances. It shouldn't be necessary to catch an exception. This is especially useful when creating instances from user input.

val date = runCatching { LocalDate(userInput.year, userInput.month, userInput.day) }.getOrNull()

Also:

• Instant.parse(…)
• TimeZone.of(…)
• etc.

Just like all similar stdlib functions have …OrNull variants.

https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07

[dkhalanskyjb]

orNull variants of TimeZone.of or Something.parse probably make sense and follow the spirit of the provided link, which describes orNull as a modifier that shows that error conditions are expected (for example, when validating user input) and must be handled.

However, why is this needed for LocalDate? Could you please describe some situations where a programmer has values for year, month, and day, then puts these values into a LocalDate constructor, which rejects them, but this error is not a logic error and can somehow be recovered from?

[fluidsonic]

User input directly from form fields.

…

On Thu, Jun 3, 2021, 12:24 dkhalanskyjb ***@***.***> wrote: orNull variants of TimeZone.of or Something.parse probably make sense and follow the spirit of the provided link, which describes orNull as a modifier that shows that error conditions are expected (for example, when validating user input) and must be handled. However, why is this needed for LocalDate? Could you please describe some situations where a programmer has values for year, month, and day, then puts these values into a LocalDate constructor, which rejects them, but this error is not a logic error and can somehow be recovered from? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUZ6RE3YWCTML5KHCHYNTTQ5Q5RANCNFSM4TOM35EQ> .

[dkhalanskyjb]

Wouldn't one want the users to know what field did they make a mistake in? null does not say much, so custom logic would be needed anyway to show a helpful error.

Better yet, why not give the users a date picker that prevents invalid dates altogether?

[fluidsonic]

Wouldn't one want the users to know what field did they make a mistake in? null does not say much, so custom logic would be needed anyway to show a helpful error.

Better yet, why not give the users a date picker that prevents invalid dates altogether?

Long-term? Probably. It's more work and probably pointless.
Short-term to get a project started in a fast & pragmatic way? No.
Also, if you rely on the browser's own date picker (HTML5 date input) some browsers may not support that. So users enter the date manually. Still needs to be checked.
Also, people understand e.g. "Your date of birth looks incorrect." just fine. There's not that much that can be wrong in a date.

I found more use-cases in my code where I use LocalDateOrNull:

• custom date picker implementation (K/JS)
• parse date from CSV import
• parse date from custom identifier that contains a date
• GraphQL date input parsing (needs custom error message, e.g. LocalDateOrNull(y,m,d) ?: graphError("message"))

[dkhalanskyjb]

What do you think of LocalDate.orNull(2024, 1, 40)?

[JakeWharton]

The lack of a verb really throws me. I would expect parseOrNull or tryParse or something. The top-level function will always match the class name/pretend to be a constructor, but a companion function could be imported and used bare without the type qualifier.

[dkhalanskyjb]

Definitely, the null-returning parsing function is going to be called parseOrNull (#508), orNull is for a nullable alternative to constructors. The problem we're trying to solve is that, for any LocalDate.fromOrNull, or LocalDate.ofOrNull, or LocalDate.createOrNull, there may be an expectation of the corresponding LocalDate.from, LocalDate.of, and LocalDate.create, which we don't want to introduce.

There isn't really a precedent for this, so we are treading new ground.

[pablichjenkov]

The problem i found with ...orNull() like functions, is that they hide the reason behind the error or failure that caused the object not being created.
Ideally builders should return a Result<E, T> type that encapsulates the actual value as Success and the failure reason as Error. But then not sure if this makes APIs verbose in general.

[dkhalanskyjb]

@pablichjenkov, in principle, sure. In this specific case, do you see different error modes of LocalDate/LocalTime/etc. constructors that you would actually like to distinguish between in your code?