Hacker News Reader

Comment by atombender | Hacker News Reader

With that scheme, what about propagating errors upwards? It seems like you have to wrap all "foreign" error types that happen during execution with an explicit enum type.

For example, let's say the function frobnicate() writes to a file and might get all sorts of file errors (disk full, no permissions, etc.). It seems like those have to be wrapped or embedded, as the article suggests.

But then you can't use the "?" macro, I think? Because wrapping or embedding requires constructing a new error value from the original one. Every single downstream error coming from places like the standard library has to go through a transformation with map_err() or similar.

View on HN

"?" call "into()" automatically, which covers simple wrapping.

The article expressly suggests not wrapping/embedding those errors but instead putting the errors into context. That suggestions starts with the sentence "Define errors in terms of the problem, not a solution" and explicitly shows a wrapping as an anti-pattern then lays out the better solution. Note that the author's solution serializes the underlying error in some cases to avoid leaking it as a dependency.

You can use ? when you implement From (to get an automatic Into) which which can be as easy as a #[from] annotation with thiserror. You can manually implement From instead of inlining the map_err if you so choose. Then you are only ever using map_err to pass additional contextual information. You usually end up using ? after map_err or directly returning the result.

I find that directly propagating errors upwards is an antipattern. In many/most cases, the caller has less information than you do for how to deal with the error. (Your library, after all, is an abstraction, of which such an error is an implementation detail.) It also prevents you from returning your own error condition which isn't one that the downstack error type can represent.

It may be that you do in fact have to throw your hands up, and propagate _something_ to the caller; in those cases, I find a Box<dyn Error> or similar better maintains the abstraction boundary.

Reply on news.ycombinator.com