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

Allow re-raising panics #236

Closed
lmb opened this issue Jun 2, 2020 · 2 comments
Closed

Allow re-raising panics #236

lmb opened this issue Jun 2, 2020 · 2 comments

Comments

@lmb
Copy link

lmb commented Jun 2, 2020

Summary

After handling a panic via Recover() or similar, I'd like the ability to re-raise the panic.

Motivation

I use sentry in a daemon which is not request oriented. There are goroutines that manage
certain aspects of a data plane. If one of them panics I'd like to log the panic to sentry, and then continue crashing.

Additional Context

I guess I could achieve this with my own wrapper around Recover:

func MyRecover() {
  err := recover()
  if err == nil {
    return
  }

  defer panic(err)
  sentry.Recover(err)
  sentry.Flush()
}

However, I'd prefer if MyRecover didn't show up on stack traces. I'm also not entirely clear whether Flush() will let me wait for that specific panic to be submitted.

@rhcarvalho
Copy link
Contributor

Hi @lmb!

In the web framework integrations we do have a Repanic option which is intended to be used when the second panic is handled either by the web framework or by your own custom code. If Repanic is used without pairing it with WaitForDelivery, then events that were not sent before the crash will be lost.

I thought this was a good opportunity to write an example of using some of the building blocks in the SDK.

The full commented example is in #241. Please have a look, we'd appreciate your feedback.


While writing the example, I saw no obvious generic solution that works for everyone.

At a minimum, there would need to be a way to configure the behavior of WaitForDelivery and the respective Timeout. If you have multiple goroutines potentially panicking concurrently, you might be better off instrumenting your code from outside, e.g. running panicky workers in a subprocess or wrapping your main program.

Here are some references related to wrapping your main program: #89 (comment), #107 (comment). The folks at dgraph have reported success with that strategy.

@rhcarvalho
Copy link
Contributor

I'll close this for now. If more people have a similar use case please comment and we can investigate if it makes sense to turn the example into a more generic yet useful helper.

https://github.com/getsentry/sentry-go/blob/1d0b5e6380374f8baea7d2eb7553154393ad99f9/example/recover-repanic/main.go

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

No branches or pull requests

2 participants