-
Notifications
You must be signed in to change notification settings - Fork 525
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
Why do some functions panic instead of returning a Result<T, E>? #556
Comments
I think those functions are intended for building timestamps from known good values. You might be looking for |
I see where you are coming from. But I do not have a String, though. I could create it to then parse it, but that feels like an ugly hack. Regardless, I was under the assumption that Rust code practices were about working with Result and Option whenever some function could fail. That Rust is reliable because runtime errors should only happen if the programmer uses unwrap() (an similar functions) or unsafe code. |
The |
Is there something I can do to move this forward? I prefer not need to check each function to see if it might panic. Maybe offer parallel functions that do not panic so it's not a breaking change? |
Feel free to submit PRs to create non-panicking alternative APIs en add deprecations for the panicking calls. |
Ok thank you, I will try to do it. Just to get a feel for naming preference, should I just add |
That seems like a reasonable first approximation. Our constructors mostly have _opt() suffixes at this point, let's see what works in context. |
Got it, will try to see if I can find a pattern. The name can always be refactored, I don't get attached to them |
Haven't forgotten about this but my schedule has been kind of full so if someone else gets to it first that's fine otherwise I will give it a go once I can put some time aside. |
Closing in favor of #1049. We have non-panicking alternatives to almost all methods now, and making them default for 0.5 is definitely on the roadmap. |
Right now I'm parsing some information I receive in UDP messages. Some of that information is timestamped but if something goes wrong on the sender I can receive random bytes so if I try to parse those bytes as dates I get a panic with 'No such local time'.
And I wonder. If the function
Local.ymd(y, month, d).and_hms(h, min, s)
can fail why not return a Result instead?The text was updated successfully, but these errors were encountered: