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
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!
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:
@user = User.find(params[:id])
and on the model
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:
@message_to_user = "It worked! Your FooBar has been connected!"
"The FooBar service is not available. Please try again later."
(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.