3 ms·

> It's true that neither rustc nor clippy complain about having a `Result<_, String>` return type. I would love to understand where the original author picked

> It's true that neither rustc nor clippy complain about having a `Result<_, String>` return type. I would love to understand where the original author picked up that unfortunate idea from. I’ve never seen someone do this, and it’s very explicitly throwing away all additional error information by converting it to strings. No wonder you can’t figure out where your errors are coming from!

steveklabnik 2y ago
If I would take a guess about a total stranger, it appears that they are a printf debugger. No shade, I am too. But it's not a huge leap to go "the thing I do with errors is print them to the screen, and you print strings to the screen, so strings make sense as error conditions." Furthermore, they seem to enjoy Go, and Go's version of Rust's Error trait provides one method, Error, which returns a string. While I haven't written meaningful Go, and can't speak to its idioms (though as far as I understand, "just turn it into a string" is not idiomatic Go), it's another sign pointing towards "the easiest way to handle errors is to just turn 'em into strings", especially if you're just trying to ship something and don't care about the details.
- stouset 2y ago
  > (though as far as I understand, "just turn it into a string" is not idiomatic Go) Sadly while I’ve seen many argue that it’s not idiomatic go, I’ve yet to see more than a handful of projects in the wild that don’t simply `return nil, err` because anything more than that is excruciating given the number of those lines in any given project.
rpbiwer2 2y ago
I can't cite my sources, but I recently started learning Rust and I've been doing this. I would guess that I picked it up from the Rust book, since that's been my primary learning source. I know I _could_ define my own error type, but that's tedious, especially if there are many types of errors to handle. For my (non-production) purposes it's been fine. What's the idiomatic way to handle errors? Is there a way to collect more detailed error information without excessive boilerplate?
- steveklabnik 2y ago
  A common but of advice is “use anyhow for applications and thiserror for libraries” but what it really boils down to is, anyhow is good for handling errors, and thiserror is good for defining your own error types. The docs have good examples of basic usage: https://docs.rs/anyhow/latest/anyhow/ https://docs.rs/anyhow/latest/anyhow/

steveklabnik 2y ago

If I would take a guess about a total stranger, it appears that they are a printf debugger. No shade, I am too. But it's not a huge leap to go "the thing I do with errors is print them to the screen, and you print strings to the screen, so strings make sense as error conditions." Furthermore, they seem to enjoy Go, and Go's version of Rust's Error trait provides one method, Error, which returns a string. While I haven't written meaningful Go, and can't speak to its idioms (though as far as I understand, "just turn it into a string" is not idiomatic Go), it's another sign pointing towards "the easiest way to handle errors is to just turn 'em into strings", especially if you're just trying to ship something and don't care about the details.

stouset 2y ago
> (though as far as I understand, "just turn it into a string" is not idiomatic Go) Sadly while I’ve seen many argue that it’s not idiomatic go, I’ve yet to see more than a handful of projects in the wild that don’t simply `return nil, err` because anything more than that is excruciating given the number of those lines in any given project.

rpbiwer2 2y ago

I can't cite my sources, but I recently started learning Rust and I've been doing this. I would guess that I picked it up from the Rust book, since that's been my primary learning source. I know I _could_ define my own error type, but that's tedious, especially if there are many types of errors to handle. For my (non-production) purposes it's been fine. What's the idiomatic way to handle errors? Is there a way to collect more detailed error information without excessive boilerplate?

steveklabnik 2y ago
A common but of advice is “use anyhow for applications and thiserror for libraries” but what it really boils down to is, anyhow is good for handling errors, and thiserror is good for defining your own error types. The docs have good examples of basic usage: https://docs.rs/anyhow/latest/anyhow/ https://docs.rs/anyhow/latest/anyhow/