Tracking issue for improving our error handling and reporting strategy #236
Labels
A-diagnostics
Area: error reporting and diagnostics
A-error-handling
Area: error handling
C-tracking-issue
Tracking issues keep track of a group of related issues or efforts
Currently, our error handling is a bit all over the place (probably mostly my fault), which makes a lot of the code very verbose in terms of error handling, even though eventually at the user-level it does not necessarily aid them troubleshooting.
There are details from lower-levels that get propagated to higher-levels, but often such details are not important to the end user.
The propagation of errors across boundaries should ideally be presented more like an error stack, so that the user sees something akin to an error cause backtrace (semantically meaningful, not just locations into the source code). I'm thinking the user should be presented with something like
color_eyre
's example:The tricky part is when we want the root cause of a failure, such as which mod got yeeted from the cache, but this is also intermixed with other errors we don't care having exact information for.
Current proposed design
error_stack
, but we don't necessarily care about having the context switches.color_eyre
or justeyre
, since it has an error stack model and supports such error traces, and it supports adding arbitrary attachments and then downcasting in higher-level code -- which is perfect for our use case since we could attach some kind ofModInfoCtxt
to errors and then attempt to downcast them when we do need exact mod info. When we don't need exact mod info, leaf errors can be rolled up into abstractReport
s which simplifies error handling alot.Implementation history
snafu
magic and use explicitthiserror
#235The text was updated successfully, but these errors were encountered: