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

#66 work in progress make print_panic_info() public #67

Merged
merged 6 commits into from
Nov 24, 2020

Conversation

kellpossible
Copy link
Contributor

Draft implementation of #66

src/writers.rs Outdated Show resolved Hide resolved
@kellpossible
Copy link
Contributor Author

Nice one @yaahc looks like you did all the hard work!

@yaahc
Copy link
Collaborator

yaahc commented Sep 29, 2020

Nice one @yaahc looks like you did all the hard work!

heh, ya, I got nerd snipped a little and then immediately after a friend asked about passing panics to tracing so I decided to not wait around and test out some things myself 😅

@kellpossible
Copy link
Contributor Author

@yaahc anything I can do to help with the PR to get it through?

@yaahc
Copy link
Collaborator

yaahc commented Oct 6, 2020

ooh, I can take care of merging it, just slipped thru the cracks is all, ty for the reminder.

@kellpossible
Copy link
Contributor Author

kellpossible commented Oct 11, 2020

I've been doing some more testing with this, and some things which would be nice, to be able to control backtrace, spantrace, and color formatting for the eyre report display invocation that gets used for sending data to sentry.

image

At the moment I have (along with a bunch of other code setting up tracing and sentry):

let (eyre_panic_hook, eyre_hook) = color_eyre::config::HookBuilder::default()
    .into_hooks();

eyre_hook.install()?;

std::panic::set_hook(Box::new(move |panic_info| {
    eprintln!("{}", eyre_panic_hook.panic_report(panic_info));
    sentry::integrations::panic::panic_handler(panic_info);
}));

Basically, it would be nice to have colours and user selectable backtrace/spantrace verbosity for what gets printed to the terminal, and for what gets sent to sentry, no colours and full verbosity on backtrace/spantrace. I've tried setting/resetting env variables on the fly but it doesn't seem to make any difference, presumably because they are only read when the hooks are created.

@kellpossible
Copy link
Contributor Author

Perhaps some of this can be achieved with the sentry-eyre integration I was playing with, I'll investigate a bit more today.

@kellpossible
Copy link
Contributor Author

kellpossible commented Oct 11, 2020

Okay I understand a bit more now, having backtrace capture enabled has performance implications, thus the decision to make it only enabled at startup via the environment variable makes a lot of sense. I guess the request for somehow being able to choose to format the error without the terminal colours still stands though.

Edit: actually I guess color codes could just be stripped from the output instead https://docs.rs/strip-ansi-escapes/0.1.0/strip_ansi_escapes/ much simpler.

@yaahc
Copy link
Collaborator

yaahc commented Oct 12, 2020

The performance implications are not really the same for eyre::Report and panic reports, so if we don't already have the ability to set independent rules for when to capture backtraces in panics and in errors I'd be happy to add that feature.

@kellpossible
Copy link
Contributor Author

Okay, thanks! I'll have a bit more of a think about it and submit a formal feature request issue if it makes sense.

@yaahc
Copy link
Collaborator

yaahc commented Nov 2, 2020

I'm sorry this has taken so long, I've not had enough mental bandwidth to do much open source work recently, but I haven't forgotten about this issue, and I'll get this finalized as soon as I can.

@yaahc yaahc marked this pull request as ready for review November 17, 2020 18:59
@yaahc
Copy link
Collaborator

yaahc commented Nov 17, 2020

alright @kellpossible how does this look? I ended up re-implementing it mostly from scratch because there's another PR that I've been sitting on for a while as well which was going to create the mother of all merge conflicts with this PR thanks to my overzealous code reorganization last time. Dreading dealing with that is a large part of why this has taken so long, once again, sorry about that. Let me know if there are any issues with the current implementation, if not I'll cut a release with this right away.

@kellpossible
Copy link
Contributor Author

No worries, figured something like that might be the case 😅 Sorry for my slow reply! I'll take a look at it today.

@kellpossible
Copy link
Contributor Author

It seems to be working fine with the latest changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants