Add non-throwing LocalDate(Time) construction & parsing

[fluidsonic]

trafficstars

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 https://github.com/Kotlin/kotlinx-datetime/issues/68#issuecomment-853795700, 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"))