4 ms·

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 application

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....)

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....)