哪裏以及如何處理導軌異常？

我目前正在參與大型Rails應用程序的開發，該應用程序通過自定義API gem與另一個產品進行交互。這導致了一種非常奇怪的錯誤捕捉。例如，當我們與其他產品交互時，它可能會返回認證錯誤，這是我們所期望的。然後，我們在我們的API gem中捕獲該錯誤並拋出異常，然後在視圖中捕獲並中繼給用戶。哪裏以及如何處理導軌異常？

我不喜歡這種錯誤方法醒目的幾個原因：

它似乎並不像我們應該期待的異常並在我們的邏輯使用它們。作爲一個例子，有時候我們想覆蓋一個對象 - 所以我們抓住「對象已經存在」的例外，並繼續前進，保存我們的模型。
它需要很多特定的錯誤捕獲。代碼中有多個區域，我們有if-elses檢查某些錯誤並進行相應的重定向。

也就是說，我是否應該充實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？

捕捉並處理模型中的異常，或將它們扔進模型並在控制器中處理它們會更好嗎？

來源

2010-06-30 NolanDC

你是在找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捕獲。

來源

2010-06-30 16:00:06

我知道rescue_from。我想我要問的一個更相關的問題是：是否使用異常來控制我的應用程序是不好的做法（如果是這樣，爲什麼？）？我應該儘可能避免例外嗎？ – NolanDC 2010-06-30 17:04:19

我認爲你應該避免它們。 – 2011-08-30 21:39:55

有人會認爲拋出它們會讓你的代碼更容易管理。向下拋出一個錯誤，並將其追上去。只要你確保事情得到正確清理。 – baash05 2012-04-18 05:47:15

哪裏以及如何處理導軌異常？

回答

相關問題