error: support core::error::Error types #177
Conversation
Support reporting errors that conform to core::error::Error. This allows for calling e.source(), which may provide more information. As an example, using the `probe-rs` gdbserver. Before: During the execution of GDB an error was encountered: Target threw a fatal error: A RISC-V specific error occurred. (No further information is available) After: During the execution of GDB an error was encountered: Target threw a fatal error: A RISC-V specific error occurred. ... caused by: Error occurred during execution of an abstract command: Exception This is gated by "std", so should not pose any API changes to deeply embedded targets.
xobs
force-pushed
the
add-core-error-support
branch
from
ad2ea07 to
1daea45
Compare
|
I'm proposing this change because in probe-rs I keep getting errors along the lines of "An error occurred in probe-rs" with no additional context, because they rely heavily on I've managed to work around it by changing the error type that gets propagated, but I think it might still be a nice feature. |
|
Cross-linking to #112 I agree that having a way to propagate the error source is useful. That said... relying on I wonder if an approach like this would work? Just riffing off the top of my head - haven't proven it out in practice. // add a new default type param to the type (which should be semver compatible?)
pub enum TargetError<E, ECore = NoCoreError> {
...
Fatal(E),
FatalCore(ECore),
}
// by default, use a ZST to make `FatalCore` be a totally noop variant
enum NoCoreError {}
impl std::core::Error for NoCoreError {}
// tweak the impl bounds here (which _should_ be semver compatible still)
#[cfg(any(feature = "std", feature = "core_error"))]
impl<T, C, ECore> CoreError for GdbStubError<T, C, ECore>
where
C: Debug + Display,
T: Debug + Display,
ECore: CoreError
{
fn source(&self) -> Option<&(dyn CoreError + 'static)> {
let GdbStubError {
kind: InternalError::FatalCore(e),
} = self
else {
return None;
};
e.source()
}
}In practice, this is a prime example of a scenario where specialization would really come in clutch, since we'd just be able to specialize the existing Let me know what you think (or if there's some obvious semver hazard / technical blocker to this idea) |
|
Specialization would make so many of these things easier, I agree. I considered the |
2 participants
Description
Add support for reporting errors that conform to core::error::Error. This allows for calling e.source(), which may provide more information. For example, probe-rs uses error sources to create chains of errors, and without this errors are very terse.
Before:
After:
This is gated by "std", so should not pose any API changes to deeply embedded targets.
API Stability
Checklist
rustdocformatting looks good (viacargo doc)examples/armv4twithRUST_LOG=trace+ any relevant GDB output under the "Validation" section below./example_no_std/check_size.shbefore/after changes under the "Validation" section belowexamples/armv4t./example_no_std/check_size.sh)ArchimplementationValidation
GDB output
armv4t output
Before/After `./example_no_std/check_size.sh` output
Before
After