Support proper grouping for repanics

[EmielM]

Our project uses quite a bit of panic()ing for flow control in http middlewares. Those middlewares functions try to recover from a panic, but only if it a panic they can handle (example: a db/tx middleware only handles panics that look like a db concurrency issues).

If the error cannot be handled, the recovered value ispaniced again -- which in practice works quite well. Go simply adds any extra panic recovery to the stack, so the first panic point can be found if you just look far enough down.

An example of a repanic raw stack trace submitted to bugsnag:

runtime.errorString runtime error: invalid memory address or nil pointer dereference 
    runtime/asm_amd64.s:479 call32
    runtime/panic.go:458 gopanic
    sqli/tx.go:74 (*Tx).runAndCommit.func1
    runtime/asm_amd64.s:479 call32
    runtime/panic.go:458 gopanic
    text/template/exec.go:140 errRecover
    runtime/asm_amd64.s:479 call32
    runtime/panic.go:458 gopanic
    runtime/panic.go:62 panicmem
    runtime/sigpanic_unix.go:24 sigpanic
    app/conv.go:151 (*ConversationRef).SomeProp
    runtime/asm_amd64.s:479 call32
    ...more

The underlying problem here is app/conv.go:151 where a nil pointer is deferenced. However, because sqli/tx.go re-panics, the error is currently grouped under sqli/tx.go:74 (runtime/ stuff is outside ProjectPackages).

I think in almost all cases the first (lowest) panic in the stack would be of most interest, so would expect the grouping logic to scan down the stack and look for the oldest panic, and then find the first function in a ProjectPackage below it.

[EmielM]

Ah yes, I'm aware I could probably bugsnag-go.errors.Wrap() the recovered values at all the sites I'm repanicing them, but that feels like quite the buy-in to your custom errors package while the actual error site can be extracted from the stack in the final recovery.

[EmielM]

After some more deliberation, I've come up with the following work-around:

func bugsnagBeforeNotify(e *bugsnag.Event, c *bugsnag.Configuration) error {
   // hack around impractical bugsnag grouping for re-panics:
   // mark re-panic stuff on the stack as not InProject
   var firstPanic int
   for i, f := range e.Stacktrace {
       if f.Method == "gopanic" {
           firstPanic = i
       }
   }
   for i := 0; i < firstPanic; i++ {
       e.Stacktrace[i].InProject = false
   }
   return nil
}

[kattrali]

I apologize for the delay here, @EmielM. This is a great idea, and probably something we could do by default. On other platforms, we already handle nested causes automatically, and could probably do the same for Go, separating each instance of gopanic. Your workaround looks like a good place to start for some test cases. I'm moving this into our roadmap as there are a few improvements we can probably make here for go stacktraces.