-
Notifications
You must be signed in to change notification settings - Fork 176
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
Consider exact policy around DateTimeError in datetime formatting #4336
Comments
Want to discuss with: |
It should be noted that the I'd like to proceed with the following solution:
OK? |
sgtm |
Using (edit: this is actually a requirement of the trait)
This is why I don't like the error enums. We have so many methods that can only error with a subset of variants, but the client always has to check all of them. Documentation is not a strong enough guarantee imho. |
Ok how about writing the string "(icu4x error)"? I don't want to carry around the Display impl for the Error type in release mode, and you get the whole error with debug assertions enabled.
I mostly agree. Not proposing to change anything right now. |
We should use a different garbage string for each code location. |
The formatters share the same code path. Neo: icu4x/components/datetime/src/raw/neo.rs Line 411 in 978ed24
Old:
The best we could do without an enum would be something like |
The GIGO doesn't have to happen at the top level that you linked. |
Hmm, replumbing the formating code is a fairly big change My main concern with the Display impl is code size. We could avoid this by using a different error struct internally that carries a static str with the additional context |
Or are you proposing that we produce outputs such as "(icu4x error: weekday names not loaded), 6 (icu4x error: month names not loaded) 2024" (instead of "Saturday, 6 January 2024") |
Yes, that |
IMO |
What are your criteria for "user friendly"? |
I think the user persona in your mind is a developer, and in my mind, end user of a product that utilizes ICU4X. Both personas are important and they should receive output adapted to their needs.
The developer seeing an erroneous output should be able to act on it, I agree. Your sample serves that well. The end user of a web browser cannot act on the error, and should see broken output in context of their UI. I believe my sample serves that better. |
The use case for this message is |
I realized that this is basically the same problem space as "GMT+?" (#2245) Along those lines, we could make up pithy error strings for each field that are both user friendly and searchable. For the month field:
Wdyt? |
Discussed in meeting to a partial conclusion
Ideas:
Agreed (amongst @zbraniecki, @robertbastian, @Manishearth):
@sffc is this okay with you (and if so, please remove the discuss label) |
I'd prefer to not include the month number because the error-state code path should be as minimal as possible; formatting "M01" is more complicated than "M" (even if only a little bit more complicated) and I want to start from the position of being as stripped-down as possible. I am happy with @zbraniecki How strongly would you like the month number to be rendered? |
Discussion with @zbraniecki:
|
Why not use Also I just realised
We're |
|
#4336 What this PR does - Stops converting datetime errors into fmt errors - Use fallback values to continue writing when an error occurs - Replaces `Writeable` by `TryWriteable` in neo - Uses lossy mode in non-neo Writeable implementations What this PR doesn't do - Use correct gigo values. For now it writes `<ICU4X ERROR>` everywhere. A domain expert should replace these by sensible values - Use a narrower error type than `DatetimeError` for `TryWriteable`
Part of #4336 Per policy in #4638 (comment)
The remaining work is semver breaking, so moving this to 2.0. |
Neo uses the new error types. @robertbastian to investigate if this is done. |
Currently there are 3 places where errors can be returned in datetime formatting:
DateTimeFormatter::try_new
DateTimeFormatter::format
FormattedDateTime::write_to
Note that case 3 is a
core::fmt::Error
whereas cases 1 and 2 areDateTimeError
. Any errors that occur duringwrite_to
are logged withlog::warn!
and then flattened to acore::fmt::Error
.Currently case 3 does not happen in normal public API usage of the icu::datetime crate. However, it is now possible to reach this case in DateTimePatternInterpolator (#3347).
If we moved this error to phase 2, we may end up slowing down the path for all users since we need to walk the whole pattern in order to figure out if the data is missing.
We should decide on this before shipping DateTimePatternInterpolator.
The text was updated successfully, but these errors were encountered: