1.dao层我是直接抛出异常，都是比较“底层”的异常，比如DataAccessException. 不捕获的原因是，假如service调用了多个dao方法，其中有一个发生了异常，如果该dao方法自己捕获了又没有重新抛出来。这时候，service事务没法回滚，因为它以为都执行正确了。
2.在service里， 调用的dao方法有可能抛出DataAccessException的话，那么service也不捕获。因为DataAccessException是runtime异常，无需强制try-catch,况且，如果你捕获了又没有抛出来，配置的事务没法感知到，因为默认只处理runtime异常，当然可以配置。
3.还可以这样，在service方法里，dao方法外面直接try-catch(Throwable e). 然后重新抛出自定义的业务相关的异常。比如TopicUpdateException.
问题：上面1,2,3我对dao层，service层的方法处理是否合理。2,3哪种更好些？为什么？
4.接上面，这个自定义的业务异常的粒度要控制到什么级别？能否举个例子
5.上面2，3 我都是用的aop统一处理异常。我看大部分人也推荐这么做。因为service层各个方法里catch里的逻辑大都相似。使用aop统一处理，好处是显而易见的。我想知道，有什么弊端吗？因为我发现公司项目几乎没有这么做的。都是直接try-catch，返回结果。要么就是上面2里提到的不捕获。出了异常反正可以记录在log里
请大家帮忙看看
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
ご招待いただきありがとうございます! しかし、私は専門家ではないことを宣言しなければなりません |_|
質問: 上記のステップ 1、2、および 3 の dao 層とサービス層に対する私のアプローチは合理的ですか? 2と3ではどちらが良いですか?
まず、ステップ 1、2、3 の分析と理解に同意します。次に、
3の処理はより適切であると思います。serviceレイヤーは純粋なデータ対話ではなくなり、Throwableをキャプチャしてより意味のある例外をスローすることで、一連のビジネス ロジック操作が含まれるからです。エラーを正確に説明できるもの）は、ログに記録されるかトランザクション処理に記録されるかに関係なく、その後の修復/エラーのトラブルシューティングに適しています4. 上記の続きですが、このカスタム ビジネス例外の粒度はどのレベルまで制御する必要がありますか?例を教えてください
粒度は要件によって異なります。たとえば、ロールバックのみを実行したい場合は、
serviceの何が間違っているかを特定できれば十分です。しかし、それでもroot causeのトラブルシューティングをさらに進めたい場合は、例外メッセージにソース エラーの詳細な説明を含めた方がよいのではないでしょうか?5. 上記 2 と 3 では、例外を一律に処理するために aop を使用します。ほとんどの人がこれを推奨していると思います。サービス層の各メソッドのキャッチのロジックはほとんど似ているためです。統合処理に aop を使用する利点は明らかです。知りたいのですが、デメリットはありますか？なぜなら、これを行う企業プロジェクトはほとんどないことがわかったからです。これらはすべて直接の try-catch であり、結果を返します。あるいは上記2で述べた非キャプチャです。例外が発生した場合は、ログ
に記録できます。まず、あなたの会社がそれをしなかった理由について話しましょう。これは、以前にフレームワークを構築した人々が
「とにかくどんな例外でもログに記録できる」については、その考えは間違っていませんが、実際に大量のログのエラーメッセージを扱ったことがある人なら理解できると思います。一律に扱えるのは当然ですが、それができていないのは設計上の欠陥やミスと考えられます。問題に対する最も効果的な解決策ではありませんaopについて十分に知らなかったか、個人的な好みを持ち込んだためである可能性があります。try catchは、アーキテクトやプログラマーに関係なく、それを熟練して自由に使用したい場合は、設計パラダイムと見なされます。コストについてはまだ学ぶ必要があります (これは欠点になる可能性があります)。理由に興味があるなら、何人かの先輩とプライベートで話してみると、もしかしたらその他の内部情報が得られるかもしれません^^aop
素人なので軽くクリックしてください^^例外を均一に処理するには Spring AOP を使用します。もちろん、3 番目の方法の方が優れています。 Spring AOP を使用して、サービス層によってスローされた例外をインターセプトし、すべての未処理の例外ログを記録し、すべての未処理の例外を統合カスタム システム例外に変換して、コントローラー層または Rpc 層がこれらのカスタム例外を処理できるようにします。情報はフロントエンドにフィードバックされます。そしてブラウザ側に表示されます。
Spring AOP を使用して例外をインターセプトする本当の機能は、例外処理ロジックを通常の処理ロジックから切り離すことであることを忘れないでください。では、例外の粒度はどのレベルで制御されていると思いますか?これはビジネス ロジックに基づいています。たとえば、データベースの追加、削除、変更、確認の操作が失敗した場合などです。外部インターフェースの呼び出しに失敗しましたか?その他異常情報等
あなたの会社のやり方は不規則で不適切です。ログを処理する場合、各 try-catch ブロックに何らかの処理コードを含める必要がある場合、例外処理コードが通常の実行コードを超えて、通常の実行コードが汚染されることがあります。 例外処理コードが散在しており、修正するのが非常に面倒です。一部の例外は一律に処理および変更することができません。
Service 内のビジネス メソッドの名前が事前定義されたルールに従って命名されていない場合、AOP はそれをインターセプトできません。つまり、トランザクション制御をロードできません。これらの命名規則は構成ファイルで指定する必要があります。
AOP 例外はすべてコントローラー層で処理します
例外は、jquery を使用しているため、フロントエンドとバックエンドが完全に分離されていません。バックエンドによって直接レンダリングされます。
- ajax 例外: を決定するためにヘッダーに X-Requested-With を含めます
- 非 ajax 例外: ajax 例外以外の
サービスクラスの各メソッドでは、メソッド全体が try catch でラップされているとは言えません。例外がデータベース例外や null ポインタなど、制御できないものに分割されているのは多すぎます。これらはキャッチする必要はありません。サービス内での異常なビジネスに基づいてスローされます。たとえば、ユーザー名が重複している場合、BizException (「重複したユーザー名」) がスローされます。ここで、BizException は RuntimeExceptionフロントデスクが顧客にエラーを表示する方法は明らかに異なるため、インターセプター (フィルター) (aop)
で個別に処理します。lz が言及した aop は例外を処理するために使用されます。上記の分析によれば、例外を処理するのがサービス層なのかコントローラー層なのかはわかりません。
これが最良の答えでない場合、それは不合理です
Spring MVC を使用していますか? Spring MVC にはグローバル例外処理があります。携帯電話では簡単に説明できません。