Expose better errors #7
Conversation
The previous errors didn't allow API consumers to inspect the underlying cause for their error. Whether it was to handle the error manually or to display a proper "error-chain" for the errors (à la `eyre`, `anyhow`, etc).
| @@ -0,0 +1 @@ | |||
| use_flake | |||
There was a problem hiding this comment.
Please remove this file and the flake files.
| @@ -1,3 +1,7 @@ | |||
| *~ | |||
| target | |||
| Cargo.lock | |||
|
|
|||
| # Nix | |||
There was a problem hiding this comment.
I'd rather keep environment-specific config out of this repository. You can always add these to your global gitignore. See https://git-scm.com/docs/gitignore. It says the default location is $XDG_CONFIG_HOME/git/ignore or if $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore.
| /// Underlying errors for [`PropertiesError`] | ||
| #[non_exhaustive] | ||
| #[derive(Debug, Error)] | ||
| pub enum PropertiesErrorCause { |
There was a problem hiding this comment.
It doesn't make sense for this struct to implement Error as well. Having separate IOError, EncodingError, etc. cases doesn't provide much benefit, because the user could always just call source() and downcast.
It probably makes more sense to create BadKeyValueSeparator and BadCommentPrefix structs, implement Error for them, make all of these direct causes of PropertiesError, and remove the PropertiesErrorCause struct.
The previous errors didn't allow API consumers to inspect the underlying cause for their error. Whether it was to handle the error manually or to display a proper "error-chain" for the errors (à la
eyre,anyhow, etc).