2016-10-18 13 views
0

現在、JHipsterの例外処理を理解しようとしています。Jhipster例外処理のサービス

サービスに例外をスローしたいと思います。例外メッセージはUIで翻訳され、メッセージのパラメータが設定されます。 CustomParameterizedExceptionは完全に適合します。しかし、建築的な観点から見ると、例外はWebパッケージにあるため、サービスでは使用できないと思います。なぜWebパッケージに入っていますか?私はそれが独自のパッケージexceptionまたはそれに似ていると期待しているので、アプリケーションのすべてのレイヤーからアクセスできます。

また、ExceptionTranslator.processRuntimeExceptionメソッドでは、注釈が例外に設定されている場合、RuntimeExceptionを処理できることが分かりました。私が見る限り、UIの翻訳はエラーコードに基づいてのみ実行されます。だから、私は必要なカスタムエラーメッセージのためにそれを使用することはできません。

jHipsterアプリケーションのWebレイヤー以外のレイヤーで例外処理をどのように行うのですか?

ご協力いただきありがとうございます。

答えて

0

CustomParameterizedExceptionは、JSONでシリアル化され、アプリケーションの角度部分で使用されるビューモデルであるParameterizedErrorVMを使用しているため、Webパッケージに含まれています。これは生成されたコードであり、必要に応じて自由に変更することができます。

Spring MVCには、blog postに示すように例外を処理するいくつかの方法があります。

また、AOPを使用して例外のログや翻訳のようなデフォルトの処理を実装することもできます(JHipsterアプリのLoggingAspectを参照)。

+0

あなたの答えをありがとう!私はそれがJHipsterによって生成される方法の意図を理解したいと思います。私の見解では、 'ParameterizedErrorVM'の使用は十分ではありません。それはサービス層のUserDTOで行われているので、DTOでもありませんか?このようにして、サービス層で例外を使用することもできます。より複雑なデータ関連の検証は、私が考えるサービス層で行う必要があります。私の意見では、ここでも 'CustomParameterizedException'も使用するのに適しています。 –

+0

githubプロジェクトでPRを自由に提案してください –

+0

申し訳ありませんが、私のアプリケーションでうまく動作するようになるとすぐにそうなります。 –