Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Background notifications could be DRYer and more complete #32

jjb opened this Issue · 7 comments

4 participants

jjb commented

Hi — thanks for reviving this project!

So I'm potentially migrating away from Exceptional, which has Exceptional::Catcher.handle_with_controller and Exceptional.handle, which are analogs to ExceptionNotifier::Notifier.exception_notification and ExceptionNotifier::Notifier.background_exception_notification.

a few things about ExceptionNotifier::Notifier.background_exception_notification

  1. it's sort of a second class citizen — it doesn't allow for custom templates
  2. it has repeated code from ExceptionNotifier::Notifier.exception_notification
  3. it's the only thing that can be appropriately used in a model (right?), so it's sort of misnamed

Maybe I'm wrong on 3, and I should just be using ExceptionNotifier::Notifier.exception_notification with an empty environment hash?

Let me know what you think — I'd be interested in cleaning it up, so that there is some sort of common method that is called in all contexts, doesn't repeat code, and reuses the templates.


not sure if I quite understood you, exceptions raised on a model are catched up by the gem without having to manually call exception_notification.
background_exception_notification is just for code that can't be reached within a request, like background tasks.

On the other hand, you're right and that piece of code is claiming for a refactor, so you're welcome to do so!

jjb commented

For example a model might access a third-party API or the filesystem, and I'd want to do something like this:

   # access the api

@smartinez87 what do you think? Am I doin' it wrong?


sorry but I still don't understand...
say you have a a controller with something like this:

def some_action
  @user = User.find(params[:id])

and on the model

def my_model_action
  access the api

Now, if something goes wrong there, it will automatically make the ExceptionNotification act and send you an email with the exception raised. Why should you manually invoke it?


Ah, whoops, I see that my example wasn't very good at all :-D. Here's something better:

def my_controller_action
    @message_to_user = "It worked! Your FooBar has been connected!"
    @message_to_user =
      "The FooBar service is not available. Please try again later."
    render 'remote_thingy_results'

(I suppose one might say that this should be caught in a library and not in the controller -- even in that case I like to use ExceptionNotifier for logging the exceptions)


@jjb: It sounds like what you're trying to do is rescue an exception in your controller and still be able to use ExceptionNotifier to be notified of that exception that you rescued. I like to use ExceptionNotifier in this way too.

@smartinez87, the reason he has to manually invoke ExceptionNotifier is because he rescued the exception in his controller. The ExceptionNotifier middleware is only able to intercept and send notifications for exceptions that are not rescued, because they have to bubble all the way up the middleware stack to ExceptionNotifier for it to become aware of them.

@jjb, I haven't used background_exception_notification before, but it sounds like in this case you could actually use the normal ExceptionNotifier::Notifier.exception_notification method instead, as mentioned in the "Manually notify of exception" section of the Readme. Also see how I'm doing it in #59.

You only need to use background_exception_notification if you don't have access to request.env.

@jweslley jweslley closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.