Berikut hanyalah amalan peribadi saya dan untuk rujukan sahaja.
Lapisan
Controller: Tanpa campur tangan AOP atau Filter, saya secara peribadi berpendapat bahawa semua pengecualian yang dihasilkan dalam kaedah di sini mesti dikendalikan;
Lapisan
: DAO Pengecualian dalam lapisan ini kebanyakannya adalah pengecualian SQL, yang biasanya dilemparkan ke lapisan untuk diproses Service
lapisan: ServiceJika dianggap pengecualian tidak memerlukan campur tangan pemanggil, ia akan dikendalikan dalam Perkhidmatan, jika tidak, ia akan dilemparkan kepada pemanggil untuk diproses (sebenarnya, ia adalah lulus daripada kesalahan...);
Hanya ada satu situasi di mana saya akan menangkap dan kemudian melontar satu lagi
, iaitu menangkap pengecualian A dan kemudian membuang pengecualian B. Ini biasanya digabungkan dengan menggunakan
untuk mengendalikan pengecualian secara seragam, contohnya: tangkap Pengecualian A, B dan C semuanya dikendalikan oleh pengendali pengecualian D Exception. AOP
Secara peribadi, saya fikir prinsip menangkap pengecualian ialah anda hanya perlu menangkap pengecualian apabila kod tersebut mempunyai keperluan pemprosesan perniagaan untuk pengecualian yang dijangkakan. Contohnya, apabila ralat SQL berlaku, anda perlu melancarkan transaksi pengecualian lain, pada dasarnya tidak perlu menangkap pengecualian Perniagaan lapisan boleh mengendalikan pengecualian secara seragam.
(1) Pengecualian yang ditandakan ditukar kepada RuntimeException Melontaran ini biasanya dianggap sebagai pepijat (2) Pengecualian tersuai (pengecualian perniagaan) diwarisi daripada RuntimeException Semasa mereka bentuk pengecualian tersuai, balingan pengecualian harus dipertimbangkan Apabila keluar, senario tidak normal boleh dihasilkan semula dengan cepat melalui maklumat log. (3) Berkenaan sama ada hendak membuang pengecualian, secara amnya, jika pemanggil perlu mengetahui bahawa pengecualian perniagaan mungkin berlaku dan boleh mengendalikannya, maka buangnya. Jika pemanggil tidak dapat mengendalikan pengecualian, ia akan ditangkap. Pendek kata, jangan "lulus". (4) Ia amat tidak disyorkan catch Exception Kod jenis ini akan menyukarkan untuk mengesan masalah dengan cepat apabila pengecualian berlaku.
Adalah disyorkan bahawa lapisan Dao melontar pengecualian terus ke atas (biasanya pengecualian masa jalan pangkalan data Lapisan Service terdedah kepada aplikasi lain, dan akan terdapat banyak maklumat perniagaan yang perlu dihantar ke). pemanggil lapisan atas , jadi berikut ialah dua cara
Maklumkan pemanggil maklumat pengecualian perniagaan khusus/maklumat pengecualian sistem dengan membuang pengecualian perniagaan (pengecualian sistem, lapisan atas mungkin tidak memberi perhatian)
Service memastikan tiada pengecualian akan berlaku dan mengembalikan Result ke lapisan atas Maklumat yang disertakan dalam Result ialah: sama ada panggilan berjaya, dan jika gagal, akan ada beberapa maklumat perniagaan
Jadi, anda tidak perlu menangkap pengecualian di semua peringkat Jika anda ingin mengendalikannya, hanya mengendalikannya dalam Service (sama ada ia adalah satu aplikasi atau perkhidmatan masa hadapan yang manakah digunakan dalam perkhidmatan bergantung kepada pasukan
yang Dipilih
Sekiranya kita menggunakan try{}catch{} untuk mengawal proses perniagaan umum, atau gunakan if() untuk mengawalnya
Berikut hanyalah amalan peribadi saya dan untuk rujukan sahaja.
LapisanController
:Tanpa campur tangan
AOP
atauFilter
, saya secara peribadi berpendapat bahawa semua pengecualian yang dihasilkan dalam kaedah di sini mesti dikendalikan; Lapisan:
DAO
Pengecualian dalam lapisan ini kebanyakannya adalah pengecualian SQL, yang biasanya dilemparkan ke lapisanuntuk diproses
Service
lapisan:
, iaitu menangkap pengecualian A dan kemudian membuang pengecualian B. Ini biasanya digabungkan dengan menggunakanService
Jika dianggap pengecualian tidak memerlukan campur tangan pemanggil, ia akan dikendalikan dalam Perkhidmatan, jika tidak, ia akan dilemparkan kepada pemanggil untuk diproses (sebenarnya, ia adalah lulus daripada kesalahan...);Hanya ada satu situasi di mana saya akan menangkap dan kemudian melontar satu lagi
untuk mengendalikan pengecualian secara seragam, contohnya: tangkap Pengecualian A, B dan C semuanya dikendalikan oleh pengendali pengecualian D
Exception
.AOP
Secara peribadi, saya fikir prinsip menangkap pengecualian ialah anda hanya perlu menangkap pengecualian apabila kod tersebut mempunyai keperluan pemprosesan perniagaan untuk pengecualian yang dijangkakan. Contohnya, apabila ralat SQL berlaku, anda perlu melancarkan transaksi pengecualian lain, pada dasarnya tidak perlu menangkap pengecualian Perniagaan lapisan boleh mengendalikan pengecualian secara seragam.
Beberapa cadangan peribadi:
(1) Pengecualian yang ditandakan ditukar kepada
RuntimeException
Melontaran ini biasanya dianggap sebagai pepijat(2) Pengecualian tersuai (pengecualian perniagaan) diwarisi daripada
RuntimeException
Semasa mereka bentuk pengecualian tersuai, balingan pengecualian harus dipertimbangkan Apabila keluar, senario tidak normal boleh dihasilkan semula dengan cepat melalui maklumat log.(3) Berkenaan sama ada hendak membuang pengecualian, secara amnya, jika pemanggil perlu mengetahui bahawa pengecualian perniagaan mungkin berlaku dan boleh mengendalikannya, maka buangnya. Jika pemanggil tidak dapat mengendalikan pengecualian, ia akan ditangkap. Pendek kata, jangan "lulus".
(4) Ia amat tidak disyorkan
catch Exception
Kod jenis ini akan menyukarkan untuk mengesan masalah dengan cepat apabila pengecualian berlaku.Adalah disyorkan bahawa lapisan
Dao
melontar pengecualian terus ke atas (biasanya pengecualian masa jalan pangkalan data LapisanService
terdedah kepada aplikasi lain, dan akan terdapat banyak maklumat perniagaan yang perlu dihantar ke). pemanggil lapisan atas , jadi berikut ialah dua caraMaklumkan pemanggil maklumat pengecualian perniagaan khusus/maklumat pengecualian sistem dengan membuang pengecualian perniagaan (pengecualian sistem, lapisan atas mungkin tidak memberi perhatian)
Service
memastikan tiada pengecualian akan berlaku dan mengembalikanResult
ke lapisan atas Maklumat yang disertakan dalamResult
ialah: sama ada panggilan berjaya, dan jika gagal, akan ada beberapa maklumat perniagaanJadi, anda tidak perlu menangkap pengecualian di semua peringkat Jika anda ingin mengendalikannya, hanya mengendalikannya dalam
yang DipilihService
(sama ada ia adalah satu aplikasi atau perkhidmatan masa hadapan yang manakah digunakan dalam perkhidmatan bergantung kepada pasukanSekiranya kita menggunakan try{}catch{} untuk mengawal proses perniagaan umum, atau gunakan if() untuk mengawalnya