2013-05-05 39 views
4

我想知道人們認爲用Clojure編寫的REST風格的api處理錯誤的好方法是使用Ring庫。在Clojure Ring REST-like API中處理錯誤?

Paul Umbers in his Clojure RESTful API tutorial採取的一種方法是讓異常自然發生並允許它們一直冒泡到專門將異常轉換爲特定HTTP狀態代碼的中間件。

基本上,DB約束會拋出自己的具體錯誤(例如PSQLException),模型驗證器會拋出另一種類型,全部在代碼400的傘下。未知異常將被泛型異常處理程序捕獲並返回500代碼。

的一點想法:

  • 我們可以做得更好?由於某些特定原因,這是錯誤的設計嗎?
  • 許多人會聲稱處理泛型異常類型是不好的做法。在這裏也可以提出這樣的論點嗎?

謝謝!

回答

1

我絕對不是這方面的專家,但是因爲沒有其他人加入,我會給我兩分錢。

您鏈接到的解決方案似乎對我來說是一個合理的方法。考慮到處理程序和異常中間件之間的少量合作,您還可以在渲染錯誤響應時使用額外的信息來標記異常,而不會將錯誤處理的實際細節嵌入到應用程序邏輯中。

因此,對於您的第一個問題:您可能會根據給定的特定用例對您的系統進行更多修改,但作爲通用錯誤處理方案,這看起來相當不錯。沒有任何關於它的東西直接跳出「錯誤」。

第二個問題:當你知道你正在尋找一個更具體的類型時,趕上通用Exception類型是個不好的習慣,因爲你想避免混淆預期和意外的錯誤。如果您知道當您執行捆綁查找時可能有MissingResourceException,那麼您不希望發生異常處理,從而意外地將NullPointerException從代碼中的實際錯誤中冒出來。

在這種情況下,我認爲捕捉通用的Exception類型是正確的做法。除了處理MissingResourceException之類的特定條件之外,此頂級處理程序的目標是捕獲您的應用程序邏輯不是的任何內容,並將其轉換爲對您的API客戶端有意義的錯誤信息。這是您的實施與其另一端的消費者之間的最後一道防線。

+0

好的,這是一個很好的解釋,非常感謝。我會用這種方法去看看它的長期運作情況。 – 2013-05-12 08:23:49