Open joecorcoran opened 4 years ago
I don't know if comparing the string description of the underlying error is the best idea.
Is there an approach that you prefer that I can help with? I guess implemeting PartialEq
is also a way forward. Right now I'm struggling to wrap this crate's error type and wondering how to move forward without resorting to converting the error to a String
.
Why do you need to compare your wrapped error for equality? There are a lot of error types in the wild that cannot do that (e.g. io::Error
, Box<dyn Error>
, ...).
Yeah I know the problem with io::Error
exists too. I want to use assert_eq!
when writing library tests to demonstrate that when the lib is used in a certain way, a particular type of error occurs, not just any error. If even one of the wrapped error types can't be compared, the whole enum can't be compared and thus the whole Result<_, Err>
can't be compared. The bad ergonomics bubble up through the codebase.
As I say above, ultimately there are ways for me to work around this, but since the error type in this crate is fairly simple and doesn't use Box<dyn ...
etc. I thought I'd try this PR out. Your call.
This helps when wrapping this crate's Error struct in another crate. Not sure if you'd like a test to cover this too, but if so just let me know.