We have a Ruby on Rails + Grape application with a lot going on. There are some places where we rescue exceptions and log messages or take corrective actions. Sometimes swallowing the exception, sometimes re-raising it.

We use Sentry as our APM. In some rescue's, we explicitly call Sentry.capture_exception(e) when we know we'll want to investigate after an error. For most "less interesting" rescues that are accepted normal operations, we don't log it to Sentry.

After yet-another uncaptured exception that we wish we could investigate, we decided to log all exceptions, even those that are, "not interesting."

What's the best way to log all rescued exception to Sentry (or Honeybadger, NewRelic, SignalFx, etc.) globally in a Rails app, and/or specifically a Grape app?

We have a Ruby on Rails + Grape application with a lot going on. There are some places where we rescue exceptions and log messages or take corrective actions. Sometimes swallowing the exception, sometimes re-raising it.

We use Sentry as our APM. In some rescue's, we explicitly call Sentry.capture_exception(e) when we know we'll want to investigate after an error. For most "less interesting" rescues that are accepted normal operations, we don't log it to Sentry.

After yet-another uncaptured exception that we wish we could investigate, we decided to log all exceptions, even those that are, "not interesting."

What's the best way to log all rescued exception to Sentry (or Honeybadger, NewRelic, SignalFx, etc.) globally in a Rails app, and/or specifically a Grape app?

• ruby-on-rails
• ruby
• exception
• sentry
• ruby-grape

1 Answer 1

I ended up adding a rescue_from callback to our base Grape-derived class:

class NiftyAPI < Grape::API
  rescue_from :all do |e|
    Rails.logger.error(e.message)
    Sentry.capture_exception(e)
    error!(e.message, e.status)
  end
end

Now, any rescued exception will get logged to Sentry.

If we find that overwhelming, we might blacklist select exception classes from getting sent to Sentry within that callback in the future. That's a more comfortable scenario that waiting to see which exceptions we explicitly want to call capture_exception on.