Capture logged messages

[epage]

Choose one: 🙋 feature request

Something I noticed in sentry, which is an enterprise-y form of human-panic, is the ability to capture logged warnings / errors. This could be a useful feature for human-panic as well to get extra context for why things might have failed.

See their log integration for their API and what features it provides.

[bltavares]

Related to the issue, I've recently came across a package which make use of the library. When debugging the report, I couldn't read a lot of the stacktrace.

The lines of the error had an .expect("some information"), but this information was not available as part of the report, nor the line number on the main.rs line. Not having that information to pinpoint where it failed made debugging much more difficult.

I was only able to discover it was that .expect after I've compiled the package without the setup_panic!() macro and found the expect.

Test case:

fn main() {
  setup_panic!();
  let a = None;
  a.expect("This should fail");
}

Copy of the error report

name = 'crossgen'
operating_system = 'unix:Debian'
crate_version = '0.5.0'
explanation = '''
Panic occurred in file 'libcore/option.rs' at line 960
'''
method = 'Panic'
backtrace = '''
stack backtrace:
   0:     0x7fb88031531c - backtrace::backtrace::trace::h3f2989054adcbdc4
   1:     0x7fb8803142d2 - <backtrace::capture::Backtrace as core::default::Default>::default::h20d6ca17f037134e
   2:     0x7fb880314348 - backtrace::capture::Backtrace::new::h39605ae6c7e75103
   3:     0x7fb88027e39c - human_panic::report::Report::new::h6787b8a063738a6c
   4:     0x7fb88027dbc2 - human_panic::handle_dump::h46959f457a9a01eb
   5:     0x7fb88004da1a - crossgen::main::{{closure}}::h113bc1f3f37497e3
   6:     0x7fb88032c483 - std::panicking::rust_panic_with_hook::he4c3a67f6258a8f9
                        at libstd/panicking.rs:515
   7:     0x7fb88032c1d9 - std::panicking::continue_panic_fmt::h156c04b2aea348c7
                        at libstd/panicking.rs:426
   8:     0x7fb88032bef5 - rust_begin_unwind
                        at libstd/panicking.rs:337
   9:     0x7fb880388fcb - core::panicking::panic_fmt::h0e6d5c6fb2a34dd6
                        at libcore/panicking.rs:92
  10:     0x7fb88037bf71 - core::option::expect_failed::h388c78b66d038dc6
                        at libcore/option.rs:960
  11:     0x7fb88004d4e1 - crossgen::main::haa2cbc59285b1ce2
  12:     0x7fb880047b06 - std::rt::lang_start::{{closure}}::h0df12d9ba1d016ae
  13:     0x7fb88032be92 - std::rt::lang_start_internal::{{closure}}::h664d976655ba006f
                        at libstd/rt.rs:59
                         - std::panicking::try::do_call::hac56dcc01f36ef70
                        at libstd/panicking.rs:310
  14:     0x7fb880350b49 - __rust_maybe_catch_panic
                        at libpanic_unwind/lib.rs:105
  15:     0x7fb880325e75 - std::panicking::try::hcda2c11533bcd35b
                        at libstd/panicking.rs:289
                         - std::panic::catch_unwind::h28820092503d86ef
                        at libstd/panic.rs:392
                         - std::rt::lang_start_internal::h249c3823b1cd2120
                        at libstd/rt.rs:58
  16:     0x7fb88004da93 - main
  17:     0x7fb87f8802e0 - __libc_start_main
  18:     0x7fb880045129 - _start
  19:                0x0 - <unknown>'''

(BTW, really nice idea of error messages. I've loved it) (Would this better be a new issue?)

[JosiahBull]

I have interest in working on this feature if it's not being done elsewhere already.

[epage]

Go for it!