3 ms·
Yeah, but that futzing typically happens separately near the "outer" error type's declaration - and when it doesn't, a concise .map_err() often does the job. I
by mcronce 3y ago
Yeah, but that futzing typically happens separately near the "outer" error type's declaration - and when it doesn't, a concise .map_err() often does the job.
It's also often taken care of by a sort thiserror macro invocation per "inner" type. There are obviously more complex error setups, but this covers the vast majority IME
- rtpg 3y agoI get why it's like this but I have often found that most of the time code ends up bailing by using a conversion into `String` quite quickly, leading to everything being stringified anyways. I get why this is, but it does make me miss the Python Exception model of "there's ~15 base exception types. One of them is probably good enough for you". One could point out that the arguments are usually "just" strings there too, but at least there's some conventions. I understand Rust's philosophy, I just find it annoying.
- mcronce 3y agoI haven't experienced that at all. Any of the codebases I've worked in - both proprietary and open-source - have converted errors to strings when it becomes necessary: When presenting it to a user, whether that means logging or placing it in an HTTP response body, etc.