This feature is enabled via
Configuration.PanicHandler,
which forks and monitors the application as a sub-process, reporting any
unhandled panics.

Reporting handled errors

Sometimes it is useful to manually notify Bugsnag of a problem. To do
this, call
bugsnag.Notify()

iferr!=nil{bugsnag.Notify(err)}

When reporting handled errors, it’s often helpful to send us custom
diagnostic data or to adjust the severity of particular errors. For more
information, see the
reporting handled errors reference.

Reporting panics from goroutines

Since goroutines are generally non-blocking, panics captured on a goroutine may
crash the application before having the opportunity to be delivered to Bugsnag
unless intentionally handled.

Use bugsnag.AutoNotify()
to notify bugsnag of a panic while letting the program continue to panic. This
is useful if you’re using a framework that already has some handling of panics
and you are retrofitting Bugsnag support.

gofunc(){deferbugsnag.AutoNotify()// ...}()

To avoid a panic in a goroutine from crashing your entire app, you can use
bugsnag.Recover()
to stop a panic from unwinding the stack any further. When Recover() is hit,
it will send any current panic to Bugsnag and then stop panicking. This is
most useful at the start of a goroutine:

gofunc(){deferbugsnag.Recover()// ...}()

Sending diagnostic data

Most functions in the Bugsnag API, including bugsnag.Notify(),
bugsnag.Recover(), bugsnag.AutoNotify(), and bugsnag.Handler() let you
attach data to the notifications that they send. To do this you pass in
rawData, which can be any of the supported types listed here.

Custom metaData appears as tabs on error reports on your Bugsnag dashboard. You
can set it by passing a
bugsnag.MetaData
object as rawData.