Exception monitoring just didn’t seem particularly important on my little open source side project, until one day I found myself tailing Heroku production logs while asking some person I didn’t know to “try it again” so that I could see the error happen before the logs disappeared into the black hole of the not-so-distant past.

How awkward.

I was a bit giddy to discover that Bugsnag loves open source, and was willing to set exercism.io up for free.

A couple of days and a bit of flailing later, I came to the unsatisfactory conclusion that I could either have a pretty error page, or I could get notified via Bugsnag automatically, but I couldn’t have both.

Getting set up in Sinatra with Bugsnag is deceptively easy:

Bugsnag.configure do |config|

config.api_key = "MY_API_KEY"

end



class App < Sinatra::Base

use Bugsnag::Rack

enable :raise_errors



get '/' do

raise 'hell'

end

end



Bugsnag is notified, and the user is presented with a plain-text response that says, simply Internal server error.

Minimalistic, yes. Lots of whitespace, yeah, that too. But to be honest, it’s boring, unfriendly, and, frankly, kind of embarrassing.

The response can be spruced up using Sinatra’s error block:

class App < Sinatra::Base

use Bugsnag::Rack

enable :raise_errors



error 500 do

erb :so_so_so_sorry

end



get '/' do

raise 'hell'

end

end



While this does result in a nice, custom error page, the drawback is that Bugsnag isn’t notified about the problem because the error block gets called before the Bugsnag::Rack middleware can jump in and get word of the exception off to the Bugsnag API.

So, forget about the Bugsnag::Rack middleware, that’s not going to work.

That said, all is not lost, because the bugsnag gem lets you trigger notifications explicitly.

error 500 do

Bugsnag.auto_notify($!)

erb :so_so_so_sorry

end



And with four lines of code you can send the most recent exception to the Bugsnag API, and provide a beautiful, friendly error message to the poor individual who encountered a problem.