Docs Platforms Go Revel
bugsnag.com Start Free Trial

Revel integration guide

Add BugSnag to your Revel applications.

This library supports revel 0.18 and above, which requires Go 1.8. To integrate with older versions of Go, check out our legacy integration.

New to BugSnag? Create an account

Looking for performance monitoring? See our performance guide

Installation

Download the code via go get:

go get github.com/bugsnag/bugsnag-go-revel

The latest available version of bugsnag-go-revel is v2.5.1.

Basic configuration

There are two steps to get panic handling in Revel apps.

  1. Add the bugsnagrevel.Filter immediately after the revel.PanicFilter in app/init.go:

    
import "github.com/bugsnag/bugsnag-go-revel"

revel.Filters = []revel.Filter{
    revel.PanicFilter,
    bugsnagrevel.Filter,
    // ...
}

  2. Set bugsnag.apikey in the top section of conf/app.conf, above the mode configurations.

    module.static=github.com/revel/revel/modules/static

bugsnag.apikey=YOUR_API_KEY_HERE

[dev]

    You can find your API key in Project Settings from your BugSnag dashboard.

Using context.Context to manage HTTP session data

We strongly recommend passing in context.Context to appropriate BugSnag calls. Passing the context.Context, found under "context" in the Args property of *revel.Controller objects, will automatically attach HTTP request data to your error reports, as well as session data that helps BugSnag track the stability of your application. For more information around how to use context.Context with BugSnag, see the context reference here.

If you are outside a request, e.g. in a separate goroutine, you can manually create the context. See session tracking for more details on creating sessions manually.

type App struct {
    *revel.Controller
}

// Get context from a Revel Controller
func (c App) Index() revel.Result {
    ctx = c.Args["context"])
}

// or from manually starting a session outside a http request
ctx = bugsnag.StartSession(context.Background())

Reporting unhandled panics

After completing installation and basic configuration, unhandled panics will be automatically reported. Error data will begin to appear in your project’s dashboard. To ensure panics from goroutines are handled effectively, see reporting panics from goroutines.

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

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. The panic will then bubble up to Revel’s panic handler.

go func(c revel.Controller) {
    defer bugsnag.AutoNotify(c.Args["context"])

    // ...
}(c)

To avoid a panic in a goroutine from bubbling any further up the stack, 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:

go func(c revel.Controller) {
    defer bugsnag.Recover(c.Args["context"])

    // ...
}(c)

Reporting handled errors

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

if err != nil {
    bugsnag.Notify(err, c.Args["context"])
}

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.

This object is automatically applied to panic reports from controller methods.

For more information around how to use context.Context with BugSnag, see the context reference here.

Sending diagnostic data

Most functions in the BugSnag API, including bugsnag.Notify(), bugsnag.Recover(), bugsnag.AutoNotify(), 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 meta data appears as tabs on error reports on your BugSnag dashboard. You can set it by passing a bugsnag.MetaData object as rawData.

bugsnag.Notify(err, c.Args["context"],
    bugsnag.MetaData{
        "Account": {
            "Name": Account.Name,
            "Paying": Account.Plan.Premium,
        },
    })

For more information, see the reporting handled errors reference.

Identifying users

User data is searchable, and the bugsnag.User.Id property powers the count of users affected. You can set which user an error affects by passing a bugsnag.User object as rawData.

bugsnag.Notify(err, c.Args["context"],
    bugsnag.User{Id: "1234", Name: "Conrad", Email: "me@example.com"})

For more information, see the reporting handled errors reference.

Session tracking

BugSnag tracks the number of “sessions” that happen within your application. This allows you to compare stability scores between releases and helps you to understand the quality of your releases.

Sessions are captured and reported by default. This behavior can be disabled using the AutoCaptureSessions configuration option.

Tracking releases

Configure your app version to see the release that each error was introduced in.

bugsnag.Configure(bugsnag.Configuration{
    AppVersion: "1.2.3",
})

Then set up a build tool integration to enable linking to code in your source control provider from the releases dashboard, timeline annotations, and stack traces.

Next steps