Skip to content

Improve error descriptiveness in the parsing API #360

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

dkhalanskyjb
Copy link
Collaborator

@dkhalanskyjb dkhalanskyjb commented Mar 4, 2024

Fixes #359
Fixes #361

Remove delayed initialization of parsing for this purpose
and document the thrown exception.
@dkhalanskyjb dkhalanskyjb requested a review from ilya-g March 4, 2024 11:06
@dkhalanskyjb dkhalanskyjb changed the title Throw a descriptive error when an ambiguous format is created Improve error descriptiveness in the parsing API Mar 4, 2024
throw DateTimeFormatException(e.message!!)
throw DateTimeFormatException(when (val message = e.message) {
null -> "The value parsed from '$input' is invalid"
else -> "$message (when parsing '$input')"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's worth adding a test or an overload of assertParsingFails that ensures that the input is present in the message

@dkhalanskyjb dkhalanskyjb requested a review from qwwdfsad March 4, 2024 15:41
@dkhalanskyjb dkhalanskyjb merged commit 02e4e4d into master Mar 18, 2024
@dkhalanskyjb dkhalanskyjb deleted the fix-error-message-on-parsing-several-varlength-fields branch March 18, 2024 10:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Potential improvements and input preservation in parsing and formatting error messages Failed requirement on strange time zone
3 participants