Dealing with foreign errors #1368
Replies: 1 comment
-
Hmm...
Maybe we can create some configurations to allow us to ignore some kinds? Say,
I am not sure, maybe create an issue at reqwest - since a lot of crates just expose errors as public fields.
This looks like a implementable thing
Btw this reminds me of a thing: When using those errors, it seems we are missing a stack trace - unlike when we are using anyhow or thiserror-with-stacktrace? I personally feel stacktrace quite helpful. |
Beta Was this translation helpful? Give feedback.
-
Since the introduction of typed-errors, I've encountered the following problem(and workarounds).
std::io::Error
since it's a foreign type, we have to mirror it.
but the underlying type is quite complex(
pub(super) struct Repr(NonNull<()>, PhantomData<ErrorData<Box<Custom>>>);
but what we can try to do instead is to use the type
ErrorKind
instd::io
, which we can acquire by calling.kind()
but now we encounter a separate issue
the check for if we implemented all variants of the
ErrorKind
enum fails, since it assumes we have to implement all the variants, including unstable onesso the only way is to create a completely custom type
reqwest::Error
Now this is interesting, since there is no default way to get the underlying Kind(it's in a private field. So we gotta use if and else if instead of the nice match statments.
hex::FromHexError
ayy an enum we can actually mi-
well, sadly the mirror feature doesn't support enums with struct variants
so we have to once again create a custom error kind type, but at least we get to use match!(which is exhausitive)
Conclusion
These from implements we have to manually imp kind of takes away the ergonomics improvements that
thiserror
provides(at least for foreign type)Beta Was this translation helpful? Give feedback.
All reactions