-
Notifications
You must be signed in to change notification settings - Fork 68
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 custom exception attributes #113
Conversation
a4cde66
to
cb87ba9
Compare
|
||
# The library expects you to define this method. You must return a Hash, | ||
# containing the keys you want to modify. | ||
def to_airbrake |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not to use some standard Ruby method like to_hash
and/or to_json
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When somebody defines a method with this name it's already clear why. It also must correspond to our API scheme, so if this was to_hash
, I would expect it to return this instead: { http_code: 404 }
. But we need the params
key, for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not convinced. You use to_hash
or something like that to serialize arrays, hashes and classes. You can just set notice.params[exception] = exc
and let serializer do its job.
But we need the params key, for example.
Do you have any other examples?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand what you want to achieve, but:
- A Hash must be returned, so we could merge it with the Notice object, so it could be filtered & truncated, if needed
- We could achieve what you suggest only if we allowed populating the "params" bit of the payload (ignoring context, session and the rest), but how useful would that be? I think we could afford it for the sake of simpler implementation, but we still can't overcome (1)
- How can we detect if we should append the exception to the Notice object? Currently we check if
to_airbrake
is defined. With your proposed API this won't be possible and we would need to donotice.params[exception] = exc
for every exception, which doesn't look good. By default,to_json
on exception object seems to be callingto_s
, so if the user doesn't define it, then we get a string like:
"params":{"exception":"\"MyException\""}
instead of
"params":{"exception":{"foo":"bar"}}
. Because of Rails' ActiveSupport your idea would work, but for vanilla Ruby it doesn't work like that, unfortunately.
P.S. This is how the exception would look like
class MyException < StandardError do
def initialize(params)
@params = params
end
end
ex = MyException.new(foo: 'bar')
# Vanilla Ruby
ex.to_json #=> "\"MyException\""
# Rails
ex.to_json #=> "{\"foo\":\"bar\"}"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am going to merge this today unless you object.
Fixes #112 (Adding to the 'params' area of airbrake.io when Airbrake.notify not explicitly called)
cb87ba9
to
968e54e
Compare
This is really great @kyrylo, thanks. Integrating with the branch at the moment - will let you know when I've had a chance to test end to end. |
Looking good - data defined by |
Awesome, I think this change will go in, but as for the next release, I can't promise it today or tomorrow (although it's possible). So, I'd say sometime next week. |
The library supports custom exception attributes. This is useful if you work | ||
with custom exceptions, which define non-standard attributes and you can't | ||
attach any additional data with help of the [`add_filter`](#airbrakeadd_filter) | ||
API due to the fact that the data isn't available at confuration time yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spelling: confuration -> configuration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, fixed!
Fixes #112 (Adding to the 'params' area of airbrake.io when
Airbrake.notify not explicitly called)