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!
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.
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.
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?
The docs have good examples of basic usage: https://docs.rs/anyhow/latest/anyhow/