我使用 Postmark 来处理 Rails 3 应用程序中的所有电子邮件,使用 postmark-rails gem。
有时,用户会引入错误的电子邮件或不存在的电子邮件,最终导致硬退回。 Postmark 会引发 Postmark::InvalidMessageError
错误来处理此问题,我的用户会收到非描述性 500 错误。
我想将这些错误处理到我的响应式界面中,我想知道什么是最好的策略。我现在已经有几个邮件程序了,其中有几十个,所以我不想向所有这些方法添加 begin-raise
块。将这个开始引发添加到控制器似乎也不是最优雅的解决方案。
我一直在阅读有关将 rescue_from
块添加到我的 ApplicationController
的内容,但是我不知道如何在界面中处理这个问题(也许通过调用使用errors
方法?)
我想在安装管道之前听听您的想法。
有什么想法吗?
I am using Postmark to handle all email in my Rails 3 app, using postmark-rails gem.
Now and then an user introduces a wrong email or a non-existing one with ends up giving hardbounces. Postmark raises Postmark::InvalidMessageError
errors to handle this issue, that my users receive as a non-descriptive 500 error.
I'd like to handle those errors into my responsive interface and I was wondering what would be the best strategy. I have now a few mailers already with several dozens amongst all, so I don't want to add begin-raise
blocks to all those methods. Adding this begin-raise to controllers also doesn't seem the most elegant solution.
I've been reading about adding a rescue_from
block to my ApplicationController
, but then I don't know how to handle this in the interface (maybe by calling a method that uses errors
method?)
I'd like to listen to your thoughts before plumbering.
Any ideas?
发布评论
评论(1)
我们必须在 Beanstalk 中处理同样的问题。首先,我们在生产中关闭了“raise_delivery_errors”,然后我们为 ActionMailer::Base 实现了一个覆盖方法,该方法允许我们针对特定的投递动态更改该设置。像这样:
这使我们能够准确控制何时出现交付异常,并避免在此类错误破坏不应破坏的内容时出现问题。通常,您只想在一两个地方放置该覆盖。在我们的例子中,它是“忘记密码”和“邀请用户”功能,此时让用户知道其密码重置电子邮件/邀请未送达至关重要。在后台运行的作业中出现交付异常对任何人都没有帮助。
完成此操作后,我们向 ApplicationController 添加了一个rescue_from,它将设置 flash[:alert] 并重定向回来。
reactivate_email_bounce_path 链接到使用 Postmark API 重新激活退回邮件的控制器。您可以在这里找到更多详细信息:
http://developer.postmarkapp.com/developer-bounces因此
,在您完成所有这些之后,您的最终用户可以在处理交付错误时获得非常好的体验,而这在网络应用程序中通常不会得到解决。在 Beanstalk 中看起来像这样:
用户不仅可以看到他的电子邮件被退回,还可以做出反应它自己:
希望这会有所帮助。
伊利亚·萨巴宁
http://twitter.com/isabanin
We had to deal with the same problem in Beanstalk. First of all we turned off "raise_delivery_errors" in production then we implemented an override method for ActionMailer::Base that allowed us to change that setting on the fly for specific deliveries. Like this:
That allowed us to control when exactly we want delivery exceptions appearing and avoid problems when such errors were breaking something they shouldn't. Usually there are only one or two places where you'd want to put that override. In our case it's Forget Password and Invite User functions, when it's crucial to let users know that their password reset email/invitation wasn't delivered. Having a delivery exceptions somewhere inside a background-running job doesn't help anyone.
After we had that in place we added a rescue_from to our ApplicationController that would set flash[:alert] and redirect back.
reactivate_email_bounce_path links to a controller that uses Postmark API to reactivate bounces. You can find more details about it here:
http://developer.postmarkapp.com/developer-bounces.html
So after you have all that in place your end user can have a pretty nice experience dealing with delivery errors, something that's not usually addressed in web apps. It looks like this in Beanstalk:
And not only a user can see that his email bounced, he can also reactive it himself:
Hope this helps.
Ilya Sabanin
http://twitter.com/isabanin