Support for :custom_message that doesn't get overridden. #111

kylev opened this Issue Aug 21, 2012 · 2 comments


None yet
3 participants

kylev commented Aug 21, 2012

Currently, when reporting an exception, the :error_message option will be overridden by the error_message attribute from the passed in exception itself, even if :error_message is specified as an option. This override is implemented in Notice#exception_attribute and friends.

In short, this doesn't do what I would hope:

Airbrake.notify(exc, :error_message => "This will ignored in favor of exc.message-derived information.")

This is reasonable, but I propose a :custom_message option that would allow developers to include relevant data about the exception that may not be directly available in the exception itself. This is particularly useful when working with libraries and we don't want to re-wrap the exception to improve the messaging.


def verify_callback
        u = User.find_by_email(email)
        return true
    rescue URI::BadURIError => e
        Airbrake.notify(e, :custom_message => "Cannot verify URL for User ID #{}")

    return false

In this case, the exception itself does not contain sufficient information to indicate which data is the problem (assuming it is difficult to look up a user by their callback_url). However, having the user's ID in a custom message means an easy lookup, data fixing, and improved validation code to prevent future errors.

I would like to see this feature. It would allow a consistent error_message from the exception, as well as provide augmented data that is invaluable for trouble shooting. It also leaves other useful slots like :parameters and :action alone with their useful default values based on Rack and the like.


benarent commented Aug 21, 2012

@kylev Thanks for creating an issue. @shime will follow up. We recently added current user in a recent update . We're still to push out a Gem but this should be live in a week or two.

Custom_message is something we're looking to support and Herb should follow up on what his thoughts are on providing this.

kylev commented Aug 21, 2012

Cool. My actual use case happens to be in a Resque context, so there is no Controller or current_user, but that's very cool.

@shime shime closed this in 8fdefb8 Aug 22, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment