拋出一個異常：字符串VS自定義類

它有什麼優勢做到：拋出一個異常：字符串VS自定義類

ApiTokenExpired = Class.new(StandardError) 
... 
raise ApiTokenExpired if response.errorCode == 429

在這個懶惰的選擇：

raise 'api token expired' if response.errorCode == 429

考慮到這個錯誤檢測代碼只發生一次？

來源

2016-01-08 Jerome Dalbert

有沒有像ApiTokenExpired自定義錯誤的一個重要的優勢，如果你必須處理錯誤以特定的方式某處調用堆棧。

begin 
    # ... 
rescue ApiTokenExpired => error 
    # handle the specific error 
rescue => error 
    # default error handling 
end

IMO決定創建自定義錯誤不取決於項目的大小或將來的維護。

由於自定義錯誤類造成額外的努力，我默認情況下不使用它。當需要特殊的錯誤處理時，應該引入一個錯誤類。

來源

2016-01-08 21:34:52 sschmeck

不知道我理解你的最後一句話。你的意思是你會在大部分時間使用自定義錯誤，因爲開銷可以忽略不計？ –

@JeromeDalbert默認情況下，我不使用自定義錯誤類。當我需要一個特定的錯誤處理，然後我使用這種方法。自定義錯誤類的開銷應該是合理的。 – sschmeck

@JeromeDalbert我在回答中修改了我的解釋。希望，現在更清楚了。 – sschmeck

有了第一個，你可以選擇通過該類時代碼被嵌入在較大的軟件挽救的錯誤。你仍然可以通過使用與錯誤消息字符串匹配的模式來做到這一點，但通常，由於重構，你可能會隨時間改變消息格式（而不是用第一種形式更改異常類），並且也可能有不同的異常具有類似的消息字符串，它們都可以破壞模式匹配。當你考慮將來的維護時，第一個更好。

來源

2016-01-08 19:48:07 sawa

它，如果你的應用程序被設計爲在未來的錯誤處理或計劃（我的意思是，任何全成系統會想，有一天，對吧？），你可以用繩子做的唯一事情就是閱讀在日誌中顯示它或者在錯誤消息中顯示它，使用類型可以以分離的方式編寫所有類型的東西。

例如，ApiTokenExpired可能可以通過「再次嘗試」響應來處理，因爲它是外部問題，或者由更新API令牌所需的步驟來處理（如果您使用了類型異常，則可以稍後插入！），也許你想要所有被認爲是SEVERE或UNEXPECTED的錯誤發送給系統管理員一封電子郵件，並存儲有關錯誤發生頻率的統計信息，鍵入的例外允許你用任何你想要的方式編碼當你的系統行爲不當時。

來源

2016-01-08 19:50:01

拋出一個異常：字符串VS自定義類

回答

相關問題