サービス層は例外をスローする必要がありますか？

Question

何らかの理由で例外をスローするのが好きではありません。私はこのヒントを再考する必要があるかどうかわかりません。

私のサービス層（Daoの+ビジネスロジックなどを使用してください）は例外をスローする必要がありますか？ ProductServiceの作成方法で

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); 

} 

だから私のオプション：

1. ユーザーが権限を持っていない場合は、必要がありますResponseオブジェクトのいくつかの並べ替えを返す例外
2. を投げます成功/失敗フラグとエラーコレクションと共に、成功した場合は新製品ID。

心に留めておくべきもの：

私もRESTfulなWebサービスにおける非Webアプリでこのサービス層を、再使用することができます。

ベストプラクティスとは何でしょうか？

Answer 1

あなたには他にどのようなオプションがあるか質問してください。例外が必要な場合もあります。あなたができる唯一の他のことは、失敗または成功のステータスを返し、適切に対処することです。

Answer 2

あなたはサービスと例外の意味に依存しますが、私が得たコンテキストでは、HTTPエンドポイントからJava例外が発生すると想定します。

答えはいいえです。サービスは、一般的な方法でエラーを公開する必要があります。 See this article on MSDN（一般的な心配はありません）。 Restfulサービスの場合は、エラーコードとともにHTTPステータスとして伝える必要があります。サービスは実装の詳細を消費者に漏らすべきではありません。それは自然な境界です。

コンシューマーは、これらのエラー状況を処理し、それを伝達する最も適切なものを決定する必要があります。それは例外を生成することを選択するかもしれません。しかし、これらの例外は、サービスがエラーコードを返す原因となった元々の問題/不作為から切り離されています。

また、@yahirは彼の言うことにもぴったりです。 HTTPサービスはHTTPエラーを公開し、別の種類のエラーを返す他のサービスを使用している可能性もありますが、ジョブはそれらを適切に処理またはマッピングすることになります。

Answer 3

サービス層は、クライアントコードに公開されている他の方法と同じように動作するはずです。結局のところ、それはまさにそれが何であるかです。

RPCを介して使用するクライアントは、この動作を正確に予測します。

RESTのような他のサイレントは、何らかの他のラッピングレイヤ（例えば、Controllerレイヤ）を介してサービスレイヤにアクセスする必要があります。このラッピングレイヤの役割の1つは、レスポンスをクライアント消費可能に変換することです。