4 ms·
Yeah, unwrap()s in examples should be written to use expect() (which spits a message and then panics). But for most example programs there's no easy way to han
by Manishearth 10y ago
Yeah, unwrap()s in examples should be written to use expect() (which spits a message and then panics).
But for most example programs there's no easy way to handle errors further than just using expect() unless you want there to be more error handling code than actual useful example code.
- pygy_ 10y agoRust n00b here (I read a lot about it but haven't written a line yet), but wouldn't `.orPanic('error message')` be a better name than `.expect('error message')`? The latter seems backwards.
- steveklabnik 10y agoIt'd be or_panic, following conventions. The idea is that I expect this to be Ok/Some, and if it's not, please use this error message.
- pygy_ 10y agoI understand the intent, but usually the programmatic object is the subject of the sentence, the method is the verb and the parameter/argument is the grammatical object. Here, the programmatic object is the grammatical object. That's what I meant by 'backwards'. could_fail().or_panic_with('message') may be even better.
- steveklabnik 10y agoI don't neccesarily disagree. Names are hard :)
- cgag 10y agoA lot of people don't seem to agree with me but I think even expect is too long of a name and terseness for commonly used names seems more important to me than reading like natural language.
- Manishearth 10y agoYou shouldn't really be using expect much :)
- cgag 10y agoIt's true I use and see unwrap more.
- Manishearth 10y agoThat's not good either :| unwrap should be confined to test and temporary code. It somewhat makes sense in example code, but expect is better for that. There are sometimes cases when you very easily know that the unwrap will never fail and if it does something has gone very horribly wrong, in which case you might use it. Libraries should keep usage of unwrap/expect to a minimum. Applications can be more liberal with it, but they should try to use expect or better error handling. Not everyone perfectly follows this, sadly. But most do.
- pygy_ 10y agoIt's at least partly a matter of affordance. You could soft-deprecate .unwrap() and .expect() (emit warnings at compile time, it will be annoying but not fatal), and provide a new version of expect with a name that's more cumbersome to type (or_panic_with(...) isn't bad in that regard, but you could do even worse... or_panic_with_error_message(...) :-).
- ben0x539 10y agoI don't think terseness helps much here, isn't the actual error message gonna dwarf the name of the method it's passed to in almost all scenarios?