Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for 'block syntax' on Bugsnag.notify calls #292

Merged
merged 1 commit into from
May 2, 2016

Conversation

loopj
Copy link
Contributor

@loopj loopj commented Apr 17, 2016

This allows users to customize the error report sent to Bugsnag using ruby block syntax on each Bugsnag.notify call as follows:

Bugsnag.notify(ex) do |notification|
  notification.severity = "info"
end

As well as being an arguably cleaner syntax than before, this also exposes the full power of accessing the Notification object to every Bugsnag.notify call - provideing a single interface to error report customization. This means Bugsnag.notify report customization and before_notify_callbacks can all share a single documentation.

This PR is the super un-opinionated version, which does not break existing APIs.

I actually propose we remove all the slightly hacky overrides logic and replace with this, which would be an api-incompatible change requiring a major version bump - any thoughts?

@snmaynard
Copy link
Contributor

This looks like a good approach to me. I've always felt that notify_or_ignore should be what notify does. If we merge this and bump the major version, how do you feel about making notify and notify_or_ignore do the same thing?

@kattrali
Copy link
Contributor

kattrali commented May 2, 2016

Looks great to me, and seems more Rubyish. Thanks, @loopj!

@kattrali kattrali merged commit 6e3f737 into master May 2, 2016
@kattrali kattrali deleted the loopj/notify-block-syntax branch June 17, 2016 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants