logoalt Hacker News

burntsushiyesterday at 10:15 PM2 repliesview on HN

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


Replies

the8472yesterday at 10:34 PM

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_runt... [1] 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 [3] https://docs.rs/password-hash/0.5.0/password_hash/errors/enu...

show 1 reply
IshKebabyesterday at 11:28 PM

Why is it an extensibility hazard (assuming you mark the `pub enum Error` as non-exhaustive)?

I mean I don't see the difference between having the non-exhaustive enum at the top level vs in a subordinate 'kind'.

show 1 reply