服務層應該拋出異常嗎？

由於某些原因，我不喜歡拋出異常，也許是因爲性能不佳，我不知道，是否應該重新考慮這個問題。服務層應該拋出異常嗎？

我的服務層（使用Dao's +業務邏輯等）應該拋出異常嗎？

public ModelAndView createProduct(@Valid ProductForm productForm, ..) { 
    ModelAndView mav = new ModelAndView(...); 

    if(bindingResult.hasErrors()) { 
    return mav; 
    } 

    // throw exception if user doesn't have permissions?? 
    productService.create(product, userPermissions); 

}

所以我在ProductService的創建方法選項：

如果用戶沒有權限，拋出一個異常
回報某種一個Response對象的，將有新產品ID是否成功，以及成功/失敗標誌和錯誤集合。

事情要記住：

我可以在非Web應用程序重新使用此服務層，也是一個RESTful Web服務。

什麼被認爲是最佳實踐？

來源

2012-05-01 loyalflow

問問自己，你有什麼其他的選擇，有時例外是必要的。唯一可以做的其他事情是返回失敗或成功的狀態並適當地處理。

來源

2012-05-01 21:11:34 JonH

取決於服務和異常的含義，但在上下文中，我將假設來自HTTP端點的java異常。

答案是否定的。服務應以一般方式暴露錯誤。 See this article on MSDN（不用擔心它是一般的）。在Restful服務錯誤的情況下，應該將其作爲帶有錯誤代碼的HTTP狀態來傳播。該服務不應將實施細節泄露給消費者。這是一個天然的邊界。

消費者應該處理這些錯誤情況，並決定最適合溝通的東西。它可能會選擇生成一個例外。但是這些例外情況與導致服務返回錯誤代碼的原始問題/概念不相容。

走得更遠我會說@yahir在他所說的也是對的。 HTTP服務會暴露HTTP錯誤，它可能只是使用下面的另一種服務返回另一種錯誤，但工作將是處理或映射它們。

來源

2012-05-01 21:17:55

我想說服務層應該像暴露給客戶端代碼的任何其他方法一樣工作。畢竟，這正是它的原因。

將通過RPC使用它的客戶端將準確預計此行爲。

其他消息，如REST，無論如何都應該通過一些其他包裝層（例如Controller層）來訪問服務層。其中一個包裝層的職責是將響應轉變爲客戶可消費的。

來源

2012-05-01 21:25:50 yair

服務層應該拋出異常嗎？

回答

相關問題