SentryFuture internally uses Hub::run which does a panic::catch_unwind that might be unnecessary.
This does lead to some very deep and confusing indirection:
4: sentry_core::futures::tests::test_futures::closure$0::async_block$0::async_block$0
at .\src\futures.rs:86
5: core::future::from_generator::impl$1::poll<enum2$<sentry_core::futures::tests::test_futures::closure$0::async_block$0::async_block_env$0> >
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
6: sentry_core::futures::impl$1::poll::closure$1<core::future::from_generator::GenFuture<enum2$<sentry_core::futures::tests::test_futures::closure$0::async_block$0::async_block_env$0> > >
at .\src\futures.rs:40
7: core::panic::unwind_safe::impl$23::call_once<enum2$<core::task::poll::Poll<tuple$<> > >,sentry_core::futures::impl$1::poll::closure_env$1<core::future::from_generator::GenFuture<enum2$<sentry_core::futures::tests::test_futures::closure$0::async_block$0::a
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\panic\unwind_safe.rs:271
8: std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<sentry_core::futures::impl$1::poll::closure_env$1<core::future::from_generator::GenFuture<enum2$<sentry_core::futures::tests::test_futures::closure$0::async_block$0::async_block_env$0
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\std\src\panicking.rs:492
9: std::panicking::try::do_catch<core::panic::unwind_safe::AssertUnwindSafe<sentry_core::session::tests::test_dont_inherit_session_backwards::closure$0::closure_env$0>,tuple$<> >
10: std::panicking::try<enum2$<core::task::poll::Poll<tuple$<> > >,core::panic::unwind_safe::AssertUnwindSafe<sentry_core::futures::impl$1::poll::closure_env$1<core::future::from_generator::GenFuture<enum2$<sentry_core::futures::tests::test_futures::closure$0
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\std\src\panicking.rs:456
11: std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<sentry_core::futures::impl$1::poll::closure_env$1<core::future::from_generator::GenFuture<enum2$<sentry_core::futures::tests::test_futures::closure$0::async_block$0::async_block_env$0> >
at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\std\src\panic.rs:137
12: sentry_core::hub::Hub::run<sentry_core::futures::impl$1::poll::closure_env$1<core::future::from_generator::GenFuture<enum2$<sentry_core::futures::tests::test_futures::closure$0::async_block$0::async_block_env$0> > >,enum2$<core::task::poll::Poll<tuple$<>
at .\src\hub.rs:233
13: sentry_core::futures::impl$1::poll<core::future::from_generator::GenFuture<enum2$<sentry_core::futures::tests::test_futures::closure$0::async_block$0::async_block_env$0> > >
at .\src\futures.rs:40I’m not entirely sure why we need panic::catch_unwind, maybe we don’t.
The nomicon says it should be used only sparingly.
The main reason for it seems to be restoring the previously existing Hub. That can as well be done with scope guards, as Drop impls are still guaranteed to run on panics.
SentryFutureinternally usesHub::runwhich does apanic::catch_unwindthat might be unnecessary.This does lead to some very deep and confusing indirection:
I’m not entirely sure why we need
panic::catch_unwind, maybe we don’t.The nomicon says it should be used only sparingly.
The main reason for it seems to be restoring the previously existing Hub. That can as well be done with scope guards, as
Dropimpls are still guaranteed to run on panics.