【问题标题】:Where and how to handle rails exceptions?在哪里以及如何处理 Rails 异常?
【发布时间】:2010-06-30 15:47:30
【问题描述】:

我目前参与开发一个大型 Rails 应用程序,该应用程序通过自定义 API gem 与另一个产品交互。这导致了一种非常奇怪的错误捕获。例如,当我们与其他产品交互时,它可能会返回我们预期的身份验证错误。然后,我们在 API gem 中捕获该错误并引发异常,然后将其捕获并转发给视图中的用户。

我不喜欢这种错误捕获方法,原因如下:

  • 似乎我们不应该期待异常并在我们的逻辑中使用它们。例如,有时我们想要覆盖一个对象——因此我们捕获“对象已存在”异常并继续保存我们的模型。
  • 它需要很多特定的错误捕获。在代码中有多个区域,我们使用 if-else 检查某些错误并进行相应的重定向。

也就是说,我是否应该充实 API gem 以拥有不引发异常的更简单的函数?是

if user.has_permission_in_product?
  if object.doesnt_exist_in_product?
    do something
  else
    redirect somewhere with errors
  end
else
  redirect somewhere else with errors
end

更喜欢

begin
  do something
rescue APIError => e
  if e.message =~ "no permission"
    redirect somewhere with errors
  elsif e.message =~ "already exists"
    redirect somewhere else with errors
  end
end

此外,如果第一个更可取,我们如何处理可能在这些函数中引发的实际 API 错误?我们是否将它们冒泡到控制器中的 rescue_from 中?

是在模型中捕获并处理异常,还是在模型中抛出并在控制器中处理?

【问题讨论】:

    标签: ruby-on-rails ruby exception-handling


    【解决方案1】:

    您在寻找rescue_from 吗?

    在您的控制器中,执行以下操作:

    class MyController < ApplicationController
        rescue_from ActiveRecord::RecordNotFound, :with => :render_missing
    
        def render_missing
            render 'This is a 404', :status => 404
        end
    end
    

    这将在每次引发ActiveRecord::RecordNotFound 异常时执行render_missing 方法。
    您可以将它与您希望的任何异常类一起使用。而且您不再需要控制器中的任何开始/救援。

    当然,模型中引发的任何异常也可以被rescue_from捕获。

    【讨论】:

    • 我知道rescue_from。我想我要问的一个更相关的问题是:使用异常来控制我的应用程序是不好的做法(如果是,为什么?)?我应该尽可能避免异常吗?
    • 我认为你应该避免使用它们。
    • 有些人会争辩说,扔掉它们会让你的代码更容易管理。把错误扔到低处,然后赶上高处。只要你确保事情得到正确清理。
    猜你喜欢
    • 2013-03-27
    • 2011-05-09
    • 2011-03-04
    • 2019-06-04
    • 2013-02-07
    • 2011-06-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多