4 ms·

I still think it's kind of mad that the standard library doesn't have better options built in. We've had long enough to explore the approaches. It's time to des

by IshKebab 11mo ago

I still think it's kind of mad that the standard library doesn't have better options built in. We've had long enough to explore the approaches. It's time to design something that can go into std and be used by everybody. As it is any moderately large Rust project ends up including several different error handling crates.

burntsushi 11mo ago
I'm on libs-api and I'd personally be on board with something like `thiserror` coming into `std`. But it would need a champion I think.
- epage 11mo ago
  I think we should provide the building blocks (display, etc like derive_more) rather than a specialized version one for errors (thiserror). I also feel thiserror encourages a public error enum which to me is an anti-pattern as they are usually tied to your implementation and hard to add context, especially if you have a variants for other error types.
  - burntsushi 11mo ago
    Yeah I used the weasel-y "something like" for exactly these reasons. :-)
  - the8472 11mo ago
    I don't quite understand the issue about public error enums? Distinguishing variants is very useful if some causes are recoverable or - when writing webservers - could be translated into different status codes. Often both are useful, something representing internal details for logging and a public interface.
    - IshKebab 11mo ago
      I agree. Is he really trying to say that e.g. errors for `std::fs::read()` should not distinguish between "file not found" and "permission denied"? It's quite common to want to react to those programmatically. IMO Rust should provide something like thiserror for libraries, and also something like anyhow for applications. Maybe we can't design a perfect error library yet, but we can do waaay better than nothing. Something that covers 99% of uses would still be very useful, and there's plenty of precedent for that in the standard library.
      - burntsushi 11mo ago
        I doubt epage is suggesting that. And note that in that case, the thing distinguishing the cause is not `std::io::Error`, but `std::io::ErrorKind`. The latter is not the error type, but something that forms a part of the I/O error type. It's very rare that `pub enum Error { ... }` is something I'd put into the public API of a library. epage is absolutely correct that it is an extensibility hazard. But having a sub-ordinate "kind" error enum is totally fine (assuming you mark it `#[non_exhaustive]`).
        the8472 11mo ago
        It's not uncommon to have it on the error itself, rather than a details/kind auxiliary type. AWS SDK does it, nested even [0][1], diesel[2], password_hash[3]. [0] https://docs.rs/aws-smithy-runtime-api/1.9.3/aws_smithy_runtime_api/client/result/enum.SdkError.html https://docs.rs/aws-smithy-runtime-api/1.9.3/aws_smithy_runt... [1] https://docs.rs/aws-sdk-s3/1.119.0/aws_sdk_s3/operation/get_object/enum.GetObjectError.html https://docs.rs/aws-sdk-s3/1.119.0/aws_sdk_s3/operation/get_... [2] https://docs.rs/diesel/2.3.5/diesel/result/enum.Error.html https://docs.rs/diesel/2.3.5/diesel/result/enum.Error.html [3] https://docs.rs/password-hash/0.5.0/password_hash/errors/enum.Error.html https://docs.rs/password-hash/0.5.0/password_hash/errors/enu...
        burntsushi 10mo ago
        Sure, I've done it too: https://docs.rs/ignore/latest/ignore/enum.Error.html https://docs.rs/ignore/latest/ignore/enum.Error.html It's not necessarily about frequency, but about extensibility. There's lot of grey area there. If you're very certain of your error domain and what kinds of details you want to offer, then the downside of a less extensible error type may never actualize. Similarly, if you're more open to more frequent semver incompatible releases, then the downside also may never actualize.
vsgherzi 11mo ago
I do think it’s just a newness issue and the community is still deciding what’s right
brabel 11mo ago
A similar problem happened with logging in Java. For many years, there were several competing libraries for logging. Eventually, the community converged on basically none of them, and it became a convention that libraries should use an implementation-agnostic logging API (slf4j), allowing applications to use their preferred implementation (which has a "bridge" to slf4j, e.g. log4j, logback etc.). Eventually, the JDK did add a logging facility [1]... but too little, too late: nobody uses that and any library that uses logging will probably forever use slf4j. [1] https://docs.oracle.com/en/java/javase/11/core/java-logging-overview.html#GUID-B83B652C-17EA-48D9-93D2-563AE1FF8EDA https://docs.oracle.com/en/java/javase/11/core/java-logging-...

burntsushi 11mo ago

I'm on libs-api and I'd personally be on board with something like `thiserror` coming into `std`. But it would need a champion I think.

epage 11mo ago
I think we should provide the building blocks (display, etc like derive_more) rather than a specialized version one for errors (thiserror). I also feel thiserror encourages a public error enum which to me is an anti-pattern as they are usually tied to your implementation and hard to add context, especially if you have a variants for other error types.
- burntsushi 11mo ago
  Yeah I used the weasel-y "something like" for exactly these reasons. :-)
- the8472 11mo ago
  I don't quite understand the issue about public error enums? Distinguishing variants is very useful if some causes are recoverable or - when writing webservers - could be translated into different status codes. Often both are useful, something representing internal details for logging and a public interface.
  - IshKebab 11mo ago
    I agree. Is he really trying to say that e.g. errors for `std::fs::read()` should not distinguish between "file not found" and "permission denied"? It's quite common to want to react to those programmatically. IMO Rust should provide something like thiserror for libraries, and also something like anyhow for applications. Maybe we can't design a perfect error library yet, but we can do waaay better than nothing. Something that covers 99% of uses would still be very useful, and there's plenty of precedent for that in the standard library.
    - burntsushi 11mo ago
      I doubt epage is suggesting that. And note that in that case, the thing distinguishing the cause is not `std::io::Error`, but `std::io::ErrorKind`. The latter is not the error type, but something that forms a part of the I/O error type. It's very rare that `pub enum Error { ... }` is something I'd put into the public API of a library. epage is absolutely correct that it is an extensibility hazard. But having a sub-ordinate "kind" error enum is totally fine (assuming you mark it `#[non_exhaustive]`).
      - the8472 11mo ago
        It's not uncommon to have it on the error itself, rather than a details/kind auxiliary type. AWS SDK does it, nested even [0][1], diesel[2], password_hash[3]. [0] https://docs.rs/aws-smithy-runtime-api/1.9.3/aws_smithy_runtime_api/client/result/enum.SdkError.html https://docs.rs/aws-smithy-runtime-api/1.9.3/aws_smithy_runt... [1] https://docs.rs/aws-sdk-s3/1.119.0/aws_sdk_s3/operation/get_object/enum.GetObjectError.html https://docs.rs/aws-sdk-s3/1.119.0/aws_sdk_s3/operation/get_... [2] https://docs.rs/diesel/2.3.5/diesel/result/enum.Error.html https://docs.rs/diesel/2.3.5/diesel/result/enum.Error.html [3] https://docs.rs/password-hash/0.5.0/password_hash/errors/enum.Error.html https://docs.rs/password-hash/0.5.0/password_hash/errors/enu...
        burntsushi 10mo ago
        Sure, I've done it too: https://docs.rs/ignore/latest/ignore/enum.Error.html https://docs.rs/ignore/latest/ignore/enum.Error.html It's not necessarily about frequency, but about extensibility. There's lot of grey area there. If you're very certain of your error domain and what kinds of details you want to offer, then the downside of a less extensible error type may never actualize. Similarly, if you're more open to more frequent semver incompatible releases, then the downside also may never actualize.

vsgherzi 11mo ago

I do think it’s just a newness issue and the community is still deciding what’s right

brabel 11mo ago

A similar problem happened with logging in Java. For many years, there were several competing libraries for logging. Eventually, the community converged on basically none of them, and it became a convention that libraries should use an implementation-agnostic logging API (slf4j), allowing applications to use their preferred implementation (which has a "bridge" to slf4j, e.g. log4j, logback etc.). Eventually, the JDK did add a logging facility [1]... but too little, too late: nobody uses that and any library that uses logging will probably forever use slf4j. [1] https://docs.oracle.com/en/java/javase/11/core/java-logging-overview.html#GUID-B83B652C-17EA-48D9-93D2-563AE1FF8EDA https://docs.oracle.com/en/java/javase/11/core/java-logging-...