4 ms·

I've never quite understood all the interest in these error-handling libraries. I've had great success even in large projects by impl'ing From when I need impli

I've never quite understood all the interest in these error-handling libraries. I've had great success even in large projects by impl'ing From when I need implicit conversion between error types. Most of the time, though, I want to actually handle the error at the calling site. I don't "bubble up" errors because they mean different things at different levels of the stack.

oconnor663 7y ago
I think the biggest benefit of these is automatic backtraces. That's what I tend to miss from e.g. Python. But this is usually more of a concern for applications than for libraries. If my application spits out "IO error: nonexistent file", I need to know which line it came from to know which file it's talking about. But in a library it's usually more obvious.
- monocasa 7y ago
  I mean, don't just bubble out errors until they lack context then. Rewrap them to add more context like ConfFileReadError(io::Error).
  - thenewwazoo 7y ago
    I wholeheartedly agree with this sentiment. Another alternative, at the cost of some log noise, is to emit a meaningful log message at every call site that has to handle the error condition.
  - shepmaster 7y ago
    That would be a major point of my library, SNAFU, discussed in the article. https://docs.rs/snafu/0.6.0/snafu/ https://docs.rs/snafu/0.6.0/snafu/
- shepmaster 7y ago
  The problem I identify with this is that the error creator needs to capture the backtrace for it to be useful. By the time the error has reached the application, the innermost parts of the stack have been popped and a backtrace is of limited usefulness. This is part of the reason that SNAFU tries to make it lightweight for library authors to add backtraces and allows application developers to turn them on.
- cesarb 7y ago
  > If my application spits out "IO error: nonexistent file", I need to know which line it came from to know which file it's talking about. Last time I needed this, I created a simple ErrorWithPath<E> wrapper around Error which also stores the path as a String, and a helper function which calls a closure and wraps any errors on its result with that wrapper. (If you want to take a look, it's at https://github.com/cesarb/filestatrec/blob/master/src/error.rs https://github.com/cesarb/filestatrec/blob/master/src/error....)
epage 7y ago
I think the interest in dynamic errors (which is what most of the error libraries deal with) comes from (1) people learning Rust and trying to get them to do something besides `unwrap`, (2) people prototyping and not wanting to use `unwrap`, and (3) applications where a lot of errors you just want to bubble up with some context.
totalperspectiv 7y ago
Coming from other languages I always thought of Errors as something 'other' that just kind of magically work within their own little exceptions code path. So in Rust I was expecting errors to be similarly complex and 'other'. I had a major aha moment recently when reading something that described errors as just types. When put that way it suddenly made so much more sense to me.

oconnor663 7y ago

I think the biggest benefit of these is automatic backtraces. That's what I tend to miss from e.g. Python. But this is usually more of a concern for applications than for libraries. If my application spits out "IO error: nonexistent file", I need to know which line it came from to know which file it's talking about. But in a library it's usually more obvious.

monocasa 7y ago
I mean, don't just bubble out errors until they lack context then. Rewrap them to add more context like ConfFileReadError(io::Error).
- thenewwazoo 7y ago
  I wholeheartedly agree with this sentiment. Another alternative, at the cost of some log noise, is to emit a meaningful log message at every call site that has to handle the error condition.
- shepmaster 7y ago
  That would be a major point of my library, SNAFU, discussed in the article. https://docs.rs/snafu/0.6.0/snafu/ https://docs.rs/snafu/0.6.0/snafu/
shepmaster 7y ago
The problem I identify with this is that the error creator needs to capture the backtrace for it to be useful. By the time the error has reached the application, the innermost parts of the stack have been popped and a backtrace is of limited usefulness. This is part of the reason that SNAFU tries to make it lightweight for library authors to add backtraces and allows application developers to turn them on.
cesarb 7y ago
> If my application spits out "IO error: nonexistent file", I need to know which line it came from to know which file it's talking about. Last time I needed this, I created a simple ErrorWithPath<E> wrapper around Error which also stores the path as a String, and a helper function which calls a closure and wraps any errors on its result with that wrapper. (If you want to take a look, it's at https://github.com/cesarb/filestatrec/blob/master/src/error.rs https://github.com/cesarb/filestatrec/blob/master/src/error....)

epage 7y ago

I think the interest in dynamic errors (which is what most of the error libraries deal with) comes from (1) people learning Rust and trying to get them to do something besides `unwrap`, (2) people prototyping and not wanting to use `unwrap`, and (3) applications where a lot of errors you just want to bubble up with some context.

totalperspectiv 7y ago

Coming from other languages I always thought of Errors as something 'other' that just kind of magically work within their own little exceptions code path. So in Rust I was expecting errors to be similarly complex and 'other'. I had a major aha moment recently when reading something that described errors as just types. When put that way it suddenly made so much more sense to me.