3 ms·

It is perhaps too verbose by default, as indicated by popularity of thiserror and anyhow crates.

by oxff 4y ago

nrc 4y ago
Many of the features of such crates are making their way to the standard library, so things will definitely improve. Figuring out what is best has taken some time and Rust has not wanted to prematurely commit.
- oxff 4y ago
  I like what the error handling achieves, it is actually readable way to understand the divergent control flow paths (and probably majority of code is read more than written), but I do not enjoy writing the initial boilerplate, so that's good to hear.
- kibwen 4y ago
  If anyone's interested in helping to shape the future of Rust's built-in error-handling story, there's an error handling project group that's been doing great work recently, e.g. the major effort to move the Error trait into libcore ( https://github.com/rust-lang/project-error-handling/issues/3 https://github.com/rust-lang/project-error-handling/issues/3 ) and stabilizing std::backtrace. You can follow along or get involved via the #project-error-handling channel on the Rust zulip: https://rust-lang.zulipchat.com/ https://rust-lang.zulipchat.com/
exDM69 4y ago
Perhaps, but it's also much better than it was two years ago and there is work going on to make it better two years in the future. A myriad of experimental prototypes (like the failure crate and its descendants) have been made, experimented with and then retired and looks like the progress is converging to these two complementary error handling crates (anyhow, thiserror, and a few mostly-compatible variants like eyre), and work going on to standardize some aspects of it so (parts of) these crates can be retired. There's also core::error that's bringing this to no-std environments. So yeah, it definitely was not great on day 1 and there's been a lot of churn on error handling but it is going in the right direction.
Ciantic 4y ago
It can be as verbose as you want. This guide as well as others suggests using concrete error types for libraries but anyhow "catch all" method for applications. There is disadvantages for going "catch all" libraries as then you can't be sure you are catching all errors.

It is perhaps too verbose by default, as indicated by popularity of thiserror and anyhow crates.

by oxff 4y ago

It is perhaps too verbose by default, as indicated by popularity of thiserror and anyhow crates.

nrc 4y ago

Many of the features of such crates are making their way to the standard library, so things will definitely improve. Figuring out what is best has taken some time and Rust has not wanted to prematurely commit.

oxff 4y ago
I like what the error handling achieves, it is actually readable way to understand the divergent control flow paths (and probably majority of code is read more than written), but I do not enjoy writing the initial boilerplate, so that's good to hear.
kibwen 4y ago
If anyone's interested in helping to shape the future of Rust's built-in error-handling story, there's an error handling project group that's been doing great work recently, e.g. the major effort to move the Error trait into libcore ( https://github.com/rust-lang/project-error-handling/issues/3 https://github.com/rust-lang/project-error-handling/issues/3 ) and stabilizing std::backtrace. You can follow along or get involved via the #project-error-handling channel on the Rust zulip: https://rust-lang.zulipchat.com/ https://rust-lang.zulipchat.com/

exDM69 4y ago

Perhaps, but it's also much better than it was two years ago and there is work going on to make it better two years in the future. A myriad of experimental prototypes (like the failure crate and its descendants) have been made, experimented with and then retired and looks like the progress is converging to these two complementary error handling crates (anyhow, thiserror, and a few mostly-compatible variants like eyre), and work going on to standardize some aspects of it so (parts of) these crates can be retired. There's also core::error that's bringing this to no-std environments. So yeah, it definitely was not great on day 1 and there's been a lot of churn on error handling but it is going in the right direction.

Ciantic 4y ago

It can be as verbose as you want. This guide as well as others suggests using concrete error types for libraries but anyhow "catch all" method for applications. There is disadvantages for going "catch all" libraries as then you can't be sure you are catching all errors.