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

Better error reporting for internal errors #215

Open
mikrostew opened this issue Dec 11, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@mikrostew
Copy link
Contributor

commented Dec 11, 2018

Issue

There are currently a number of Notion internal errors in the code:

$ grep -nIr "\.unknown()" crates/ src/ | wc -l
      82

Normally users should not run into these, but when they do there is not much info provided about what happened so that we can reproduce the error.

Proposal

For internal errors, I propose that we:

  1. Log the error details to a file (backtrace, environment, whatever we can get)
  2. Include the location of that file in the error message describing how to report the error, so that the use can include it

@mikrostew mikrostew referenced this issue Dec 11, 2018

Merged

Separate Inventory and Toolchain types #181

17 of 17 tasks complete
@dherman

This comment has been minimized.

Copy link
Collaborator

commented Dec 13, 2018

Some thoughts about RUST_BACKTRACE: I feel like we shouldn't expose this environment variable to the public UX of Notion. (It bugs me that Rust exposes this for every program ever.) Maybe we can do something like unconditionally always generate a full backtrace (by modifying RUST_BACKTRACE to "full" on startup, but restoring it to its initial state whenever we shell out to another process? by using backtrace? by using failure? needs more investigation).

@dherman

This comment has been minimized.

Copy link
Collaborator

commented Dec 13, 2018

To clarify: unconditionally always generate a full backtrace, but NOTION_DEV just controls whether that only goes in a log file or also gets printed out to stderr. I 100% agree with you that we should generate this info in an error log file for diagnostic purposes; NOTION_DEV becomes more of a convenience for quick debugging by notion developers, for spitting out diagnostic info in CI, etc.

@dherman

This comment has been minimized.

Copy link
Collaborator

commented Dec 13, 2018

We could also investigate what human-panic is doing. I'm not sure it's the right abstraction for us to use but maybe it is. And even if not, we can learn from how they work.

@rwjblue rwjblue referenced this issue Dec 13, 2018

Open

Full MVP #150

6 of 8 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.