Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for improving our error handling and reporting strategy #236

Open
1 task
jieyouxu opened this issue Aug 8, 2024 · 0 comments
Open
1 task
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

Comments

@jieyouxu
Copy link
Collaborator

jieyouxu commented Aug 8, 2024

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:

    color-eyre on  hooked [$!] is 📦 v0.5.0 via 🦀 v1.44.0
    ❯ RUST_LIB_BACKTRACE=1 cargo run --example usage
        Finished dev [unoptimized + debuginfo] target(s) in 0.04s
         Running `target/debug/examples/usage`
    Jul 05 19:16:02.853  INFO read_config:read_file{path="fake_file"}: Reading file
    Error:
       0: Unable to read config
       1: No such file or directory (os error 2)
    
  • 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

  • A concept similar to error_stack, but we don't necessarily care about having the context switches.
  • We probably want to transition to color_eyre or just eyre, 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 of ModInfoCtxt 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 abstract Reports which simplifies error handling alot.

Implementation history

@jieyouxu jieyouxu added C-tracking-issue Tracking issues keep track of a group of related issues or efforts A-diagnostics Area: error reporting and diagnostics A-error-handling Area: error handling labels Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

1 participant