3 ms·

I like this book a lot, but the writers use an external package to handle errors. Why don’t you just return a Result<T, Box<dyn Error>> instead?

swsieber 6y ago
Disclaimer: takes this with a grain of salt as I do use Box<dyn Error>. But I have a couple of things to note. 1. error chain is not the recommended way, despite being in the book. It needs updating! 2. The error trait in the std has come a long way since the book was originally written 3. You still might want some nicities that that Box<dun Error> doesn't provide you, and so you'd define an enum. You can do it manually, or use a library like anyhow or thiserror depending on if you're an app or library. 4. Rust error handling has been in a lot of flux, but generally improving. It probably does deserve a dedicated section in the book. I recommend this blog post: https://nick.groenen.me/posts/rust-error-handling/ https://nick.groenen.me/posts/rust-error-handling/
- michael_j_ward 6y ago
  Just adding this video [0] that both gives a mental framework for designing errors and a "lay-of-the-land" for current libraries. Jane, the speaker, also heads up Rust's error handling project group [1], and gives her thoughts on future design / work. [0] https://www.youtube.com/watch?v=rAF8mLI0naQ https://www.youtube.com/watch?v=rAF8mLI0naQ [1] https://blog.rust-lang.org/inside-rust/2020/09/18/error-handling-wg-announcement.html https://blog.rust-lang.org/inside-rust/2020/09/18/error-hand...
- gsserge 6y ago
  > I recommend this blog post: https://nick.groenen.me/posts/rust-error-handling/ https://nick.groenen.me/posts/rust-error-handling/ This blog post is good indeed. The discussion on /r/rust linked at the end of the post is also worth reading. Another good and light introduction is http://www.sheshbabu.com/posts/rust-error-handling/ http://www.sheshbabu.com/posts/rust-error-handling/ And a more in-depth look https://blog.burntsushi.net/rust-error-handling/ https://blog.burntsushi.net/rust-error-handling/
gsserge 6y ago
One thing that is useful to keep in mind when considering boxed errors or error-like objects, e.g. anyhow::Error, is that they famously do not implement std::error::Error trait [1]. This could be a problem if you want to use a third-party API where generic functions or structs use std::error::Error in their trait bounds. For example, fn use_error<E: std::error::Error>(e: E) { ... } will not compile with a boxed error as the parameter. [1] https://users.rust-lang.org/t/shouldnt-box-t-where-t-error-implement-error-regardless-whether-t-sized/48605 https://users.rust-lang.org/t/shouldnt-box-t-where-t-error-i...
steveklabnik 6y ago
This actually goes to the root of why this project exists. There is a pretty deep tension in the way that Rust deals with stability. That is, the project itself takes stability very seriously, and as such, has to minimize, to some degree, what things we accept as official, because we need to be able to maintain them. So what tends to happen is, stuff happens in the ecosystem, and then, if it makes sense, moves slowly into the project itself. Furthermore, because being blessed by the project commands some weight, if we refer to something, it'll get used. But if we want the ecosystem to explore the design space and develop solutions, endorsing something in the midst of that process could cut it short. This also means that the documentation, generally, doesn't refer to any external projects. We need stuff to be solid and foundational, but some random package can change at whatever pace they'd like. We also don't want to interfere with the community development process by picking winners. But you, as a Rust developer, programming something, need to know how to get stuff done. And that very often will mean interacting with the ecosystem. That's a good thing! But that comes in tension with the docs provided by the project. Because you won't learn about serde from reading the book. --------------- There is a second issue here, which is the kind of documentation provided by the project. We have good beginner documentation. We have good expert documentation. But how do you get from point A to point B? It's a bit less clear. Additionally, our beginner documentation tends to be focused on doing, and our expert documentation tends to be focused on more abstract theory or implementation details. Where we are weakest is "okay I read the book... now what?" --------------- One method of resolving these tensions is the Cookbook. The idea was to provide a resource based around helping intermediate Rust developers solve specific tasks. The usual guidelines around referring to packages is relaxed a bit. It wouldn't be pointing to the absolute latest fancy stuff, but it would be allowed to refer to packages that have mostly settled out. If you're doing serialization, you may not use serde, but you probably are, and nobody is going to be surprised if you do. So on some level, we want to provide a resource to folks that are saying "Hey I need to deserialize this JSON, what should I do?" and be able to say "Use serde." This may mean that the cookbook would need changing if the ecosystem shifts significantly. There's an art to doing this enough to be useful, but not enough to cause constant churn. ---------------- Unfortunately, a lot of folks put a lot of effort into the cookbook, but then moved on to other things. It's needed some revitalization for a while, and never quite made it over the hump from "in-progress work" to "thing we're willing to publish and promote." It got close! It's still really good in many places! It's also out of date in places. ---------------- Anyway, that's a really long way of saying "because real world programs don't tend to use Result<T, Box<dyn Error>> except at the exploratory phase."
volta83 6y ago
> Why don’t you just return a Result<T, Box<dyn Error>> instead? Because this book is old and outdated.

swsieber 6y ago

Disclaimer: takes this with a grain of salt as I do use Box<dyn Error>. But I have a couple of things to note. 1. error chain is not the recommended way, despite being in the book. It needs updating! 2. The error trait in the std has come a long way since the book was originally written 3. You still might want some nicities that that Box<dun Error> doesn't provide you, and so you'd define an enum. You can do it manually, or use a library like anyhow or thiserror depending on if you're an app or library. 4. Rust error handling has been in a lot of flux, but generally improving. It probably does deserve a dedicated section in the book. I recommend this blog post: https://nick.groenen.me/posts/rust-error-handling/ https://nick.groenen.me/posts/rust-error-handling/

michael_j_ward 6y ago
Just adding this video [0] that both gives a mental framework for designing errors and a "lay-of-the-land" for current libraries. Jane, the speaker, also heads up Rust's error handling project group [1], and gives her thoughts on future design / work. [0] https://www.youtube.com/watch?v=rAF8mLI0naQ https://www.youtube.com/watch?v=rAF8mLI0naQ [1] https://blog.rust-lang.org/inside-rust/2020/09/18/error-handling-wg-announcement.html https://blog.rust-lang.org/inside-rust/2020/09/18/error-hand...
gsserge 6y ago
> I recommend this blog post: https://nick.groenen.me/posts/rust-error-handling/ https://nick.groenen.me/posts/rust-error-handling/ This blog post is good indeed. The discussion on /r/rust linked at the end of the post is also worth reading. Another good and light introduction is http://www.sheshbabu.com/posts/rust-error-handling/ http://www.sheshbabu.com/posts/rust-error-handling/ And a more in-depth look https://blog.burntsushi.net/rust-error-handling/ https://blog.burntsushi.net/rust-error-handling/

gsserge 6y ago

One thing that is useful to keep in mind when considering boxed errors or error-like objects, e.g. anyhow::Error, is that they famously do not implement std::error::Error trait [1]. This could be a problem if you want to use a third-party API where generic functions or structs use std::error::Error in their trait bounds. For example, fn use_error<E: std::error::Error>(e: E) { ... } will not compile with a boxed error as the parameter. [1] https://users.rust-lang.org/t/shouldnt-box-t-where-t-error-implement-error-regardless-whether-t-sized/48605 https://users.rust-lang.org/t/shouldnt-box-t-where-t-error-i...

steveklabnik 6y ago

This actually goes to the root of why this project exists. There is a pretty deep tension in the way that Rust deals with stability. That is, the project itself takes stability very seriously, and as such, has to minimize, to some degree, what things we accept as official, because we need to be able to maintain them. So what tends to happen is, stuff happens in the ecosystem, and then, if it makes sense, moves slowly into the project itself. Furthermore, because being blessed by the project commands some weight, if we refer to something, it'll get used. But if we want the ecosystem to explore the design space and develop solutions, endorsing something in the midst of that process could cut it short. This also means that the documentation, generally, doesn't refer to any external projects. We need stuff to be solid and foundational, but some random package can change at whatever pace they'd like. We also don't want to interfere with the community development process by picking winners. But you, as a Rust developer, programming something, need to know how to get stuff done. And that very often will mean interacting with the ecosystem. That's a good thing! But that comes in tension with the docs provided by the project. Because you won't learn about serde from reading the book. --------------- There is a second issue here, which is the kind of documentation provided by the project. We have good beginner documentation. We have good expert documentation. But how do you get from point A to point B? It's a bit less clear. Additionally, our beginner documentation tends to be focused on doing, and our expert documentation tends to be focused on more abstract theory or implementation details. Where we are weakest is "okay I read the book... now what?" --------------- One method of resolving these tensions is the Cookbook. The idea was to provide a resource based around helping intermediate Rust developers solve specific tasks. The usual guidelines around referring to packages is relaxed a bit. It wouldn't be pointing to the absolute latest fancy stuff, but it would be allowed to refer to packages that have mostly settled out. If you're doing serialization, you may not use serde, but you probably are, and nobody is going to be surprised if you do. So on some level, we want to provide a resource to folks that are saying "Hey I need to deserialize this JSON, what should I do?" and be able to say "Use serde." This may mean that the cookbook would need changing if the ecosystem shifts significantly. There's an art to doing this enough to be useful, but not enough to cause constant churn. ---------------- Unfortunately, a lot of folks put a lot of effort into the cookbook, but then moved on to other things. It's needed some revitalization for a while, and never quite made it over the hump from "in-progress work" to "thing we're willing to publish and promote." It got close! It's still really good in many places! It's also out of date in places. ---------------- Anyway, that's a really long way of saying "because real world programs don't tend to use Result<T, Box<dyn Error>> except at the exploratory phase."

volta83 6y ago

> Why don’t you just return a Result<T, Box<dyn Error>> instead? Because this book is old and outdated.