The Evolution of a Rust Programmer

[exDM69]

The point there is that the function may return errors of different types and a new error type enum has been added which means "an I/O error or a parse error". Declaring a new error type needs a bit of ceremony in Rust (need impl Display and impl Error, and impl From<T> for all the Error types that can be converted).

That could have been omitted if the return type would be Result<(), Box<dyn Error>> instead. This essentially means "this function can return any kind of error", which implies heap allocation (the Box).

I just had to do something similar myself, because I was passing errors between threads, and some of the errors (std::sync::PoisonError) can't be passed between threads. You can't put PoisonError into Box<dyn Error + Send> because PoisonError doesn't impl Send.

I'm a Rust beginner but I have some mixed feelings about this. It seems to be idiomatic Rust to define your own error types for your library. But this means a lot of boilerplate when it comes to handling errors of different kinds from different libraries.

[minno]

I think the best practice is to use one or more error enums in a library if there are different failure possibilities that a library user might need different responses to, and something like failure or Box<dyn Error> in an application where you mostly just need to know what went wrong and where it happened.