I would love to see us improving the built-in Error. I agree that we don't want to "pick a winner", but we do want to merge the key *functionality* people want. In particular, I think we want 90% of "anyhow" (especially contexts, chains, and bail!/format_err!).
-
-
-
I also think we should have a built-in derive(Error) with some of the functionality of thiserror, that also supports deriving From impls. Needs to have the same property that thiserror touts, that it writes the same code you would by hand, and switching to by-hand isn't breaking.
- Još 2 druga odgovora
Novi razgovor -
-
-
I think this ties a little more closely than might be expected into finalising async/.await, TBH. Similar issues in terms of needing to drive a real push to consensus, including changing some minds. Nice .await? library ergonomics will collide on return error types RSN.
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
-
-
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
-
-
I pretty much avoid error handling besides std::io::Result because I can't be arsed to get anything else working.
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
-
-
As an intermediate Rust user, it still isn’t clear to me what the “paved road” for error handling should be. Aspects in the standard library still feel clunky. Very much appreciate your post and desire to improve this area!
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.
