Open AaronKutch opened 1 month ago
After you bubble up the error, are you reflecting on the structure of the error (e.g., downcasting it back to its concrete type and matching on it) or are you just pretty-printing it as a human readable message?
If it's the latter, then instead we recommend eagerly calling .to_string()
on the error, and bubbling up that message instead. For example, if you were use eyre
, you might do: .map_err(|error| Report::msg(error.to_string()))
.
No there is nothing particularly special I am doing, various error frameworks take anything that implements Error
. The new error types have a Src
that can be very useful, but due to lifetime constraints it often cannot be returned. The documentation notes this and explicitly recommends .map_src(drop)
, but due to the strange bounds (the traits don't seem to actually be used unless I am missing something obvious?) it does not implement Error
. I could just use .ok()
and propogate a None
instead, but it would be nice to have the new extra error information. I also definitely do not want to allocate strings in my use case.
The definition in the source code is
impl<Src, Dst: ?Sized> Error for AlignmentError<Src, Dst>
where
Src: Deref,
Dst: KnownLayout,
{
}
but why is the Deref
bound required in the first place? Maybe there is some alternate error format that can easily be converted to with some other function on the CastError
type? Have a shorthand for .map_src(drop)
or whatever it is?
For AlignmentError
, we require Deref
so we can print the source address and what power of 2 it's a multiple of.
When trying to use the errors in certain ways, I get errors with certain error frameworks because simple things will not enable the
Error
impls such asAre these bounds really needed? It causes issues where I can't propogate errors in simple cases:
which gives the error
There are other impls that have the same problem