airbrake/airbrake — pull request #350 by boblail (2014-11-25 20:32:56+00:00)
Title: Allowed custom exceptions to provide more context to Airbrake

#### The problem I'm having

The Airbrake gem allows you to set parameters when you notify of an exception (`Airbrake.notify($!, parameters: {})`); but I often call `Airbrake.notify` several frames away from the method that is raising the exception (particularly when the exception is I/O related) — and it would be useful to provide additional context.

I could move calls to `Airbrake.notify` to lower-level sections of code; but this has two drawbacks:

1. More calls to `Airbrake.notify` are scattered throughout the codebase. (It's harder to call that—and configure it as—a generic policy.)
2. Frames _between_ the one raising the exception and the one notifying Airbrake can no longer rescue from specific exceptions and recover.

#### This proposed solution

It would be ideal if I could add more information to an exception at its source (or even progressively attach context to it as it works its way up the stack!) and to report all that to Airbrake.

In this Pull Request, new notices merge the result of `exception.airbrake_parameters` into `Notice#parameters` if `exception` responds to `airbrake_parameters`.

#### Example of using it

This, of course, lets exceptions provide additional context to Airbrake; and it seems to me that it should be easy to implement by users of the gem with modules:

```ruby
module SuppliesHttpResponseToAirbrake
def airbrake_parameters
{request_method: request.method, request_url: request.url, response_code: status}
end
end

# ...

def a_method_that_makes_a_web_request
# ...
rescue HTTP::ServerError => exception
exception.extend SuppliesHttpResponseToAirbrake
raise exception
end
```