Talk about fine-grained vs shared error types

[dtolnay]

Some std APIs use one-off error types, as in str::from_utf8 and <usize as FromStr>::from_str. On the other hand io::Error is used very broadly. Talk about tradeoffs and recommendations around this.

[kallisti5]

The rust error types are one of the on-going hardest things to deal with since i've started learning rust. I come from several languages (C, C++, Ruby, Golang, Python).

I'm constantly searching the documentation for what errors are returned by what functions. This gets frustrating at times because I end up spending more time trying to figure out how to handle basic error cases vs doing actual work.

POSIX solved this long ago with basic categories that are flexible enough to adapt to the context their returned in.

For example:

• Parsing a float to a string? B_MISMATCHED_VALUES
• Network read error? B_IO_ERROR
• Network timeout? B_BUSY
• Error marshaling a string to a struct? B_MISMATCHED_VALUES

Sure, you have B_MISMATCHED_VALUES twice in there.. but you also have the context when making the call to understand what is going on and how to handle it properly.

[dtolnay]

The next step would be to make a list of error types in popular libraries and categorize them on a spectrum from fine-grained to overarching. Then we can get a better sense of the tradeoffs in each direction, and hopefully distill a guideline out of that.

[dtolnay]

Let's give this some time as the failure design shakes out.

[kallisti5]

I wrote my comments before I fully understood using Box and From to wrap errors, but the bigger question is, does Rust want to rely on From for making errors generic, or does rust want to implement a universal generic error/failure type?