Commits on Feb 5, 2018

1. Add singleton class extension support to Bugsnag::Middleware::Excepti… …

   …onMetaData
   
   Using `Bugsnag::MetaData` to attach metadata or other Bugsnag-specific data directly to an exception class works great for the common case:
   
   ```
   class MySpecialError < StandardError
     include Bugsnag::MetaData
   end
   
   error = MySpecialError.new("Oh no!")
   error.bugsnag_meta_data = {foo: :bar}
   ```
   
   However, it doesn't support dynamically extending an exception class at runtime.
   
   ```
   begin
     do_a_thing
   rescue => e
     e.extend(Bugsnag::MetaData)       # extend singleton class
     e.bugsnag_meta_data = {foo: :bar} # add context
     raise e                           # re-raise, let other code send to Bugsnag
   end
   ```
   
   This used to work in Bugsnag 5.1.0 [1] but broke when a type check was added in 6.0.0 [2].
   
   This commit changes the implementation to use `respond_to?` over a type check. This offers a more flexible interface. For example, an exception need not include `Bugsnag::MetaData` directly, they need only to define the `bugsnag_meta_data` method.
   
   This change also applies to `bugsnag_user_id`, `bugsnag_context`, and `bugsnag_grouping_hash`.
   
   [1] https://github.com/bugsnag/bugsnag-ruby/blob/v5.1.0/lib/bugsnag/notification.rb#L311-L317
   [2] https://github.com/bugsnag/bugsnag-ruby/blob/94cea3195d0fb3b3ed1c79ab38d9d4b1b9a732a3/lib/bugsnag/middleware/exception_meta_data.rb#L10

   

   jnraine committed Feb 5, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for f62cf92
   • Browse repository at this point

   Copy the full SHA

   f62cf92 View commit details

   Browse the repository at this point in the history