javaWeb项目使用aop处理异常？

Question

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里

请大家帮忙看看

Answer 1

Terima kasih atas jemputan! Tetapi saya perlu mengisytiharkan bahawa saya bukan pakar |_|

Soalan: Adakah pendekatan saya terhadap lapisan dao dan lapisan perkhidmatan dalam langkah 1, 2 dan 3 di atas munasabah? Mana satu lebih baik, 2 atau 3?

Pertama sekali, saya bersetuju dengan analisis dan pemahaman anda dalam langkah 1, 2 dan 3. Kedua, saya fikir pemprosesan 3 adalah lebih sesuai, kerana lapisan service bukan lagi interaksi data tulen, tetapi mengandungi satu siri operasi logik perniagaan Dengan menangkap Throwable dan kemudian membuang Pengecualian yang lebih bermakna (. yang boleh menerangkan ralat dengan tepat), sama ada direkodkan dalam log atau pemprosesan transaksi, adalah lebih sesuai untuk kemungkinan penyelesaian masalah/ralat berikutnya

4 Meneruskan daripada perkara di atas, ke tahap apakah perincian pengecualian perniagaan tersuai ini harus dikawal? Boleh beri saya contoh

Kebutiran bergantung pada keperluan Sebagai contoh, jika anda hanya mahu melakukan rollback, maka selagi anda dapat mengesan apa yang service salah, itu sudah memadai untuk anda. Tetapi jika anda masih mahu menyelesaikan masalah selanjutnya root cause, bukankah lebih baik untuk memasukkan lebih banyak penerangan tentang ralat sumber dalam mesej pengecualian?

5 Dalam 2 dan 3 di atas, saya menggunakan aop untuk mengendalikan pengecualian secara seragam. Saya rasa kebanyakan orang mengesyorkan ini. Kerana logik dalam tangkapan dalam setiap kaedah lapisan perkhidmatan kebanyakannya serupa. Faedah menggunakan aop untuk pemprosesan bersatu adalah jelas. Saya ingin tahu, adakah terdapat kekurangan? Kerana saya mendapati hampir tiada projek syarikat melakukan ini. Kesemuanya adalah cubaan tangkap langsung dan hasil pulangan. Atau ia bukan tangkapan yang disebut dalam 2 di atas. Jika pengecualian berlaku, ia boleh direkodkan dalam log

Pertama sekali, mari kita bincangkan tentang sebab syarikat anda tidak berbuat demikian. Ini mungkin disebabkan oleh sebab sejarah Orang yang membina rangka kerja sebelum ini tidak cukup mengetahui tentang aop, atau mereka membawa pilihan peribadi mereka. bekerja dan memilih untuk pergi terus ke mana-mana try catch(kaedah ini Mudah dan kasar, paling mudah dikuasai), aop dianggap sebagai paradigma reka bentuk sama ada arkitek atau pengaturcara, mereka masih perlu belajar untuk menguasainya dan menggunakannya secara bebas (ini mungkin merugikan). Jika anda berminat dengan sebabnya, sebaiknya berbual dengan beberapa rakan sekerja senior secara tertutup, mungkin anda boleh mendapatkan maklumat dalaman yang lain^^

Mengenai "sebarang pengecualian boleh direkodkan dalam log pula", idea itu tidak salah, tetapi orang yang sebenarnya telah menangani mesej ralat dalam log besar akan faham. Adalah jelas bahawa ia boleh dikendalikan secara seragam, tetapi ia tidak dilakukan. Ini dianggap sebagai kecacatan atau kesilapan reka bentuk. Bukan penyelesaian yang paling berkesan untuk masalah

Saya orang awam, sila klik ringan^

Answer 2

Gunakan Spring AOP untuk mengendalikan pengecualian secara seragam Sudah tentu, kaedah ketiga adalah lebih baik. Gunakan Spring AOP untuk memintas pengecualian yang dilemparkan oleh lapisan perkhidmatan, merekodkan semua log pengecualian yang tidak dikendalikan dan menukar semua pengecualian yang tidak dikendalikan kepada pengecualian sistem tersuai bersatu supaya lapisan pengawal atau lapisan Rpc boleh mengendalikan pengecualian tersuai ini Maklumat disalurkan kembali ke bahagian hadapan. dan dipaparkan pada bahagian pelayar.
Jangan lupa, fungsi sebenar menggunakan Spring AOP untuk memintas pengecualian adalah untuk memisahkan logik pemprosesan pengecualian daripada logik pemprosesan biasa. Jadi pada tahap manakah yang anda fikir butiran pengecualian dikawal? Ini berdasarkan logik perniagaan anda. Sebagai contoh, operasi menambah, memadam, mengubah suai dan menyemak pangkalan data gagal? Gagal memanggil antara muka luaran? Maklumat abnormal lain, dsb.
Kaedah syarikat anda adalah tidak teratur dan tidak sesuai. Semasa memproses log, anda perlu memasukkan beberapa kod pemprosesan dalam setiap blok cuba-tangkap Kadangkala kod pengendalian pengecualian adalah lebih daripada kod pelaksanaan biasa, mencemarkan kod pelaksanaan biasa. Kod pengendalian pengecualian bertaburan dan sangat menyusahkan untuk diubah suai. Sesetengah pengecualian tidak boleh dikendalikan dan diubah suai secara seragam.
Jika penamaan kaedah perniagaan dalam Perkhidmatan tidak dinamakan mengikut peraturan yang telah ditetapkan, AOP tidak boleh memintasnya. Dengan kata lain, kawalan transaksi tidak boleh dimuatkan. Konvensyen penamaan ini perlu dinyatakan dalam fail konfigurasi.

Answer 3

Kami semua mengendalikan pengecualian aop dalam lapisan pengawal
Pengecualian dibahagikan kepada pengecualian bukan ajax dan pengecualian ajax Kerana kami menggunakan jquery, bahagian hadapan dan bahagian belakang tidak dipisahkan sepenuhnya dipaparkan secara langsung oleh bahagian belakang

1. pengecualian ajax: Mengandungi X-Requested-With dalam pengepala untuk menentukan

2. Pengecualian bukan ajax:
   selain pengecualian ajax Cara meja depan anda memaparkan ralat kepada pelanggan pastinya berbeza, jadi kendalikannya secara berasingan dalam Interceptor (penapis) (aop)

Dalam setiap kaedah kelas perkhidmatan, tidak dikatakan bahawa keseluruhan kaedah dibalut dengan tangkapan cuba Itu terlalu banyak Pengecualian dibahagikan kepada perkara yang tidak dapat anda kawal, seperti pengecualian pangkalan data, penunjuk nol, dll. Ini tidak perlu ditangkap. Dalam perkhidmatan Ia dilemparkan berdasarkan perniagaan yang tidak normal dalam perniagaan Contohnya, jika nama pengguna diulang, saya akan membuang BizException ("Nama pengguna pendua"), di mana BizException mewarisi RuntimeException<.>

lz menyebut aop untuk mengendalikan pengecualian saya tidak tahu sama ada anda berada dalam lapisan perkhidmatan atau lapisan pengawal Jelas sekali mengikut analisis saya di atas, ia harus dilakukan dalam lapisan pengawal

Jika ini bukan jawapan yang terbaik, ia adalah tidak munasabah

Answer 4

Adakah anda menggunakan spring mvc? Spring MVC mempunyai pengendalian pengecualian global Anda boleh mencarinya Saya tidak dapat menyatakan butirannya dengan mudah pada telefon bimbit saya.