The current error handling situation in the password-hash crate seems both overcomplicated and has other issues which limit the ability to easily map between error types in important scenarios.
This actually ended up indirectly leading to a panic in the argon2 crate (RustCrypto/password-hashes#135) due to an unimplemented!() macro triggered by an unexpected error when an appropriate conversion wasn't possible.
Looking at that issue and the comments I brought up, here are some high-level concerns it raised:
- Large number of error types, and sometimes it's unclear which to use
- Important cases not handled:
HasherError does not have a way to provide salt-related errors (this is a result of some refactoring work where salt-related error types were lost)
- The
password_hash::Output::init_with API is problematic because it uses a closure and mandates the use of OutputError from that closure. It could perhaps be improved by being generic over the error type, since in practical contexts a user will almost always want HasherError, but in other cases may want a concrete crate-level error type. Another solution might be to find a way to avoid using a closure entirely.
The current error handling situation in the
password-hashcrate seems both overcomplicated and has other issues which limit the ability to easily map between error types in important scenarios.This actually ended up indirectly leading to a panic in the
argon2crate (RustCrypto/password-hashes#135) due to anunimplemented!()macro triggered by an unexpected error when an appropriate conversion wasn't possible.Looking at that issue and the comments I brought up, here are some high-level concerns it raised:
HasherErrordoes not have a way to provide salt-related errors (this is a result of some refactoring work where salt-related error types were lost)password_hash::Output::init_withAPI is problematic because it uses a closure and mandates the use ofOutputErrorfrom that closure. It could perhaps be improved by being generic over the error type, since in practical contexts a user will almost always wantHasherError, but in other cases may want a concrete crate-level error type. Another solution might be to find a way to avoid using a closure entirely.