all Error types should be public?

[getreu]

In order to test the error behaviour of a function you need an error struct to compare with. For example:
since ParseIntError is private, I have to generate one by doing something wrong, like u8::from_str("257"). This leads to the following test:

let pie_overflow      = u8::from_str("257").unwrap_err();
assert_eq!(super::Missions::parse_enc_opt("ascii,256,U+41..U+67",8).unwrap_err(), pie_overflow );

If error types where public I would rather instantiate one and write:

let pie_overflow  = ParseIntError {kind: std::num::Overflow};
assert_eq!(super::Missions::parse_enc_opt("ascii,256,U+41..U+67",8).unwrap_err(), pie_overflow );

Maybe there is a reason I do not see why they are private and there is better more idiomatic way of doing error comparison?

[niconii]

Maybe a dupe of #22639, though this might be more about a general principle for Error types.

[Mark-Simulacrum]

@rust-lang/libs, this seems relevant to the libz blitz and associated API guideline generation.

[dtolnay]

Thanks! I filed rust-lang/api-guidelines#69 to follow up with a guideline.

[aturon]

We discussed this in the libs team meeting today. The problem with allowing public constructors is that it precludes you ever extending the error with additional fields or variants.

An alternative is to make sure there are enough public accessors that you can write tests using the accessors, rather than by ginning up an error.

[getreu]

An alternative is to make sure there are enough public accessors that you can write tests using the accessors, rather than by ginning up an error.
Thank you. Could you please point me to a piece of code how to implement it?

[aturon]

@getreu So for ParseIntError today, there's not any information in the error itself, so you just want to assert .is_err().