Apakah menangkap pengecualian umum benar-benar hal yang buruk?

57

Saya biasanya setuju dengan sebagian besar peringatan analisis kode, dan saya berusaha untuk mematuhinya. Namun, saya mengalami kesulitan dengan yang ini:

CA1031: Jangan menangkap jenis pengecualian umum

Saya mengerti alasan untuk aturan ini. Tetapi, dalam praktiknya, jika saya ingin mengambil tindakan yang sama terlepas dari pengecualian yang dilontarkan, mengapa saya harus menangani masing-masing secara khusus? Selanjutnya, jika saya menangani pengecualian tertentu, bagaimana jika kode yang saya panggil perubahan untuk melemparkan pengecualian baru di masa depan? Sekarang saya harus mengubah kode saya untuk menangani pengecualian baru itu. Sedangkan jika saya hanya menangkap Exceptionkode saya tidak perlu berubah.

Misalnya, jika Foo memanggil Bar, dan Foo perlu berhenti memproses terlepas dari jenis pengecualian yang dilemparkan oleh Bar, apakah ada keuntungan untuk menjadi spesifik tentang jenis pengecualian yang saya tangkap?

Mungkin contoh yang lebih baik:

public void Foo()
{
    // Some logic here.
    LogUtility.Log("some message");
}

public static void Log()
{
    try
    {
        // Actual logging here.
    }
    catch (Exception ex)
    {
        // Eat it. Logging failures shouldn't stop us from processing.
    }
}

Jika Anda tidak menangkap pengecualian umum di sini, maka Anda harus menangkap setiap jenis pengecualian yang mungkin. Patrick punya poin bagus yang OutOfMemoryExceptiontidak boleh ditangani dengan cara ini. Jadi bagaimana jika saya ingin mengabaikan setiap pengecualian tetapi OutOfMemoryException?

c# design exceptions

— Bob Horn
sumber

12

Bagaimana dengan OutOfMemoryException? Kode penanganan yang sama dengan yang lainnya?

— Patrick

@ Patrick Poin bagus. Saya menambahkan contoh baru dalam pertanyaan saya untuk mencakup pertanyaan Anda.

— Bob Horn

1

Menangkap pengecualian umum sama buruknya dengan membuat pernyataan umum tentang apa yang Anda semua harus lakukan. Pada umumnya tidak ada pendekatan satu ukuran untuk semua.

4

@Patrick itu OutOfMemoryError, yang terpisah dari Exceptionpohon warisan karena alasan itu

— Darkhogg

Bagaimana dengan pengecualian keyboard, seperti Ctrl-Alt-Del?

— Mawg

33

Aturan-aturan ini umumnya merupakan ide yang bagus dan karenanya harus diikuti.

Tapi ingat ini adalah aturan umum. Mereka tidak mencakup semua situasi. Mereka menutupi situasi yang paling umum. Jika Anda memiliki situasi tertentu dan Anda dapat membuat argumen bahwa teknik Anda lebih baik (dan Anda harus dapat menulis komentar dalam kode untuk mengartikulasikan argumen Anda untuk melakukannya) kemudian lakukan (dan kemudian kaji sejawat).

Di sisi berlawanan dari argumen.

Saya tidak melihat contoh Anda di atas sebagai situasi yang baik untuk melakukannya. Jika sistem logging gagal (mungkin mencatat beberapa pengecualian lain) maka saya mungkin tidak ingin aplikasi untuk melanjutkan. Keluar dan cetak pengecualian ke output sehingga pengguna dapat melihat apa yang terjadi.

— Martin York
sumber

2

Setuju. Pada sangat Setidaknya , sekarang penebangan biasa offline membuat semacam ketentuan yang akan memberi beberapa jenis output debugging, untuk STDERR jika tidak ada yang lain.

— Shadur

6

Saya membesarkan hati Anda berdua, tetapi saya pikir Anda berpikir seperti pengembang, bukan pengguna. Seorang pengguna umumnya tidak peduli apakah logging sedang terjadi, asalkan aplikasi dapat digunakan.

— Mawg

1

Menarik, karena log4net secara eksplisit tidak ingin menghentikan aplikasi hanya karena logging gagal. Dan saya pikir itu tergantung pada apa yang Anda login; audit keamanan, tentu saja, matikan prosesnya. Tapi debug log? Tidak terlalu penting.

— Andy

1

@Andy: Yap semuanya tergantung pada apa yang Anda lakukan.

— Martin York

2

Mengapa Anda tidak memahaminya? Dan sebaiknya Anda tidak berusaha untuk melakukannya?

— Mawg

31

Ya, menangkap pengecualian umum adalah hal yang buruk. Pengecualian biasanya berarti bahwa program tidak dapat melakukan apa yang Anda minta.

Ada beberapa jenis pengecualian yang dapat Anda tangani:

Pengecualian fatal : kehabisan memori, tumpukan meluap, dll. Beberapa kekuatan gaib baru saja mengacaukan alam semesta Anda dan prosesnya sudah sekarat. Anda tidak dapat memperbaiki situasinya jadi menyerah saja
Pengecualian karena bug dalam kode yang Anda gunakan : Jangan mencoba menanganinya, tetapi perbaiki sumber masalahnya. Jangan gunakan pengecualian untuk kontrol aliran
Situasi luar biasa : Hanya menangani pengecualian dalam kasus ini. Di sini kita dapat memasukkan: kabel jaringan dicabut, koneksi internet berhenti berfungsi, izin hilang, dll.

Oh, dan sebagai aturan umum: jika Anda tidak tahu apa yang harus dilakukan dengan pengecualian jika Anda menangkapnya, lebih baik gagal cepat (berikan pengecualian ke penelepon dan biarkan itu menanganinya)

— Victor Hurdugaci
sumber

1

Bagaimana dengan kasus spesifik dalam pertanyaan? Jika ada bug dalam kode logging, mungkin tidak apa-apa untuk mengabaikan pengecualian, karena kode yang sebenarnya penting seharusnya tidak terpengaruh oleh hal itu.

— svick

4

Mengapa tidak memperbaiki bug di kode logging?

— Victor Hurdugaci

3

Victor, itu mungkin bukan bug. Jika disk tempat tinggal log kehabisan ruang, apakah itu bug dalam kode logging?

— Carson63000

4

@ Carson63000 - yah, ya. Log tidak ditulis, oleh karena itu: bug. Menerapkan log berputar ukuran tetap.

— detly

5

Ini adalah jawaban terbaik imo, tetapi hilang satu aspek penting: keamanan . Ada beberapa pengecualian yang terjadi karena orang-orang jahat mencoba menjebak program Anda. Jika ada pengecualian yang tidak dapat Anda tangani, maka Anda tidak perlu lagi mempercayai kode itu. Tidak ada yang suka mendengar bahwa mereka menulis kode yang membiarkan orang-orang jahat masuk

— riwalk

15

Lingkaran luar paling atas harus memiliki salah satu dari ini untuk mencetak semua yang bisa, dan kemudian mati kematian yang mengerikan, kekerasan dan BISING (karena ini seharusnya tidak terjadi dan seseorang perlu mendengar).

Kalau tidak, Anda biasanya harus sangat berhati-hati karena kemungkinan besar Anda belum mengantisipasi segala sesuatu yang dapat terjadi di lokasi ini, dan karenanya kemungkinan besar tidak akan memperlakukannya dengan benar. Buat sespesifik mungkin sehingga Anda hanya menangkap orang-orang yang Anda kenal akan terjadi, dan biarkan mereka yang tidak terlihat sebelumnya menggelembung hingga kematian yang disebutkan di atas.

1

Saya setuju dengan ini dalam teori. Tapi bagaimana dengan contoh logging saya di atas? Bagaimana jika Anda ingin mengabaikan pengecualian logging dan melanjutkan? Haruskah Anda perlu menangkap setiap pengecualian yang dapat dilemparkan dan menangani masing-masing sambil membiarkan pengecualian yang lebih serius muncul?

— Bob Horn

6

@ BobHorn: Dua cara memandang itu. Ya, Anda dapat mengatakan bahwa penebangan tidak terlalu penting dan jika gagal maka aplikasi Anda seharusnya tidak dihentikan. Dan itu poin yang cukup adil. Tapi, bagaimana jika aplikasi Anda gagal login selama lima bulan dan Anda tidak tahu? Saya telah melihat ini terjadi. Dan kemudian kami membutuhkan log. Bencana. Saya menyarankan melakukan segala yang dapat Anda pikirkan untuk menghentikan penebangan yang gagal lebih baik daripada mengabaikannya saat itu terjadi. (Tapi Anda tidak akan mendapatkan banyak konsensus tentang itu.)

— pdr

@ pdr Dalam contoh logging saya, saya biasanya akan mengirim peringatan email. Atau, kami memiliki sistem untuk memantau log, dan jika sebuah log tidak diisi secara aktif, tim dukungan kami akan mendapatkan peringatan. Jadi kami menyadari masalah logging dengan cara lain.

— Bob Horn

@BobHorn contoh logging Anda agak dibuat-buat - kebanyakan kerangka logging yang saya tahu, berusaha keras untuk tidak membuang pengecualian dan tidak akan dipanggil seperti itu (karena akan membuat "pernyataan log terjadi pada baris X di file Y" tidak berguna )

@ pdr Saya telah mengajukan pertanyaan di daftar logback (Java) tentang cara membuat kerangka logging menghentikan aplikasi jika konfigurasi logging gagal, hanya karena sangat penting kita memiliki log, dan setiap kegagalan diam tidak dapat diterima. Solusi yang bagus masih tertunda.

9

Bukannya itu buruk, hanya saja tangkapan spesifik lebih baik. Ketika Anda spesifik, itu berarti Anda benar-benar memahami, lebih konkret, apa yang sedang dilakukan aplikasi Anda, dan memiliki kontrol lebih besar terhadapnya. Secara umum, jika Anda menemukan situasi di mana Anda hanya menangkap Pengecualian, catat dan lanjutkan, mungkin ada beberapa hal buruk yang terjadi. Jika Anda secara khusus menangkap pengecualian yang Anda tahu bisa dilewati oleh blok kode atau metode, maka ada kemungkinan lebih tinggi Anda benar-benar dapat memulihkan daripada hanya mencatat dan berharap yang terbaik.

— Ryan Hayes
sumber

5

Dua kemungkinan itu tidak saling eksklusif.

Dalam situasi yang ideal, Anda akan menangkap semua jenis pengecualian yang dapat dihasilkan oleh metode Anda, menanganinya berdasarkan per pengecualian, dan pada akhirnya menambahkan catchklausa umum untuk menangkap pengecualian di masa depan atau tidak dikenal. Dengan cara ini Anda mendapatkan yang terbaik dari kedua dunia.

try
{
    this.Foo();
}
catch (BarException ex)
{
    Console.WriteLine("Foo has barred!");
}
catch (BazException ex)
{
    Console.WriteLine("Foo has bazzed!");
}
catch (Exception ex)
{
    Console.WriteLine("Unknown exception on Foo!");
    throw;
}

Ingatlah bahwa untuk menangkap pengecualian yang lebih spesifik, Anda harus mengutamakan mereka.

Sunting: Untuk alasan yang disebutkan dalam komentar, tambahkan rethrow di tangkapan terakhir.

— Rotem
sumber

2

Tunggu. Mengapa Anda ingin mencatat pengecualian yang tidak diketahui untuk menghibur dan melanjutkan? Jika itu pengecualian yang bahkan Anda tidak tahu bisa dilemparkan oleh kode, Anda mungkin berbicara tentang kegagalan sistem. Melanjutkan skenario ini mungkin ide yang sangat buruk.

— pdr

1

@ pdr Tentunya Anda menyadari bahwa ini adalah contoh yang dibuat-buat. Intinya adalah untuk mendemonstrasikan penangkapan penangkapan pengecualian spesifik dan umum, bukan bagaimana menanganinya.

— Rotem

@Rotem Saya pikir Anda punya jawaban yang bagus di sini. Tapi pdr ada benarnya. Kode, seperti, membuatnya terlihat seperti menangkap dan melanjutkan baik-baik saja. Beberapa pemula, melihat contoh ini, mungkin berpikir itu pendekatan yang bagus.

— Bob Horn

Dibuat atau tidak, itu membuat jawaban Anda salah. Segera setelah Anda mulai menangkap pengecualian seperti Kehabisan Memori dan Disk Penuh dan hanya menelannya, Anda membuktikan mengapa menangkap pengecualian umum sebenarnya buruk.

— pdr

1

Jika Anda menangkap pengecualian umum hanya untuk login, maka Anda harus rethrow setelah login.

— Victor Hurdugaci

5

Saya telah merenungkan hal yang sama baru-baru ini, dan kesimpulan sementara saya adalah bahwa hanya pertanyaan yang muncul karena hirarki .NET Exception sangat kacau.

Ambil contoh, kandidat rendahan ArgumentNullExceptionyang mungkin merupakan kandidat yang masuk akal untuk pengecualian yang tidak ingin Anda tangkap, karena cenderung mengindikasikan bug dalam kode daripada kesalahan runtime yang sah. Ah iya. Begitu juga NullReferenceException, kecuali itu NullReferenceExceptiontidak berasal dari SystemExceptionlangsung, jadi tidak ada ember Anda dapat menempatkan semua "kesalahan logis" ke dalam menangkap (atau tidak menangkap).

Lalu ada kegagalan utama IMNSHO untuk SEHExceptionmemperoleh (melalui ExternalException) SystemExceptiondan dengan demikian menjadikannya "normal"SystemException Ketika Anda mendapatkanSEHException, Anda ingin menulis dump dan mengakhiri secepat mungkin - dan mulai dengan .NET 4 setidaknya beberapa Pengecualian SEH dianggap Pengecualian Keadaan Korup yang tidak akan ditangkap. Suatu hal yang baik, dan fakta yang membuatCA1031aturan itu semakin tidak berguna, karena sekarang malas Andacatch (Exception)tidak akan menangkap tipe terburuk ini.

Kemudian, tampaknya hal-hal Kerangka Kerja lain agak tidak konsisten diperoleh baik Exceptionsecara langsung atau melalui SystemException, membuat upaya pengelompokan klausa menangkap sesuatu seperti sesuatu yang diperdebatkan.

Ada karya Mr. Lippert yang C#terkenal, yang disebut Vexing Exception , di mana ia menjabarkan beberapa kategorisasi pengecualian: Anda bisa berargumen bahwa Anda hanya ingin menangkap yang "eksogen", kecuali ... C#bahasa dan desain .NET pengecualian kerangka kerja membuat mustahil untuk "menangkap hanya yang eksogen" dengan cara ringkas. _{(dan, misalnya, seorang OutOfMemoryExceptionmungkin sangat baik menjadi kesalahan dipulihkan benar-benar normal untuk API yang memiliki mengalokasikan buffer yang entah bagaimana besar)}

Intinya bagi saya adalah, bahwa cara C#menangkap blok bekerja dan cara hierarki pengecualian Kerangka dirancang, aturan di CA1031luar sama sekali tidak berguna . Ia berpura - pura membantu dengan akar masalah "jangan menelan pengecualian" tetapi menelan pengecualian tidak ada hubungannya dengan apa yang Anda tangkap, tetapi dengan apa yang kemudian Anda lakukan:

Ada setidaknya 4 cara untuk sah menangani tertangkap Exception, dan CA1031hanya tampaknya dangkal menangani salah satu dari mereka (yaitu kasus re-throw).

Sebagai catatan, ada fitur C # 6 yang disebut Filter Pengecualian yang akan membuat CA1031sedikit lebih valid lagi sejak itu Anda akan dapat memfilter dengan benar, benar, memfilter pengecualian yang ingin Anda tangkap, dan ada sedikit alasan untuk menulis tanpa filter catch (Exception).

— Martin Ba
sumber

1

Masalah utama OutOfMemoryExceptionadalah bahwa tidak ada kode cara yang baik dapat memastikan bahwa itu "hanya" menunjukkan kegagalan alokasi tertentu yang dipersiapkan untuk gagal. Ada kemungkinan bahwa beberapa pengecualian lain yang lebih serius dilemparkan, dan OutOfMemoryExceptionterjadi selama tumpukan terlepas dari pengecualian lain itu. Java mungkin terlambat ke pesta dengan "coba-dengan-sumber dayanya", tetapi menangani pengecualian selama tumpukan sedikit lebih baik daripada .NET.

— supercat

1

@supercat - cukup benar, tapi itu cukup benar untuk semua pengecualian Sistem umum lainnya, ketika hal-hal menjadi buruk di setiap blok akhirnya.

— Martin Ba

1

Itu benar, tetapi orang dapat (dan umumnya harus) menjaga finallyblok terhadap pengecualian yang secara realistis dapat diharapkan terjadi sedemikian rupa sehingga pengecualian asli dan baru keduanya bisa dicatat. Sayangnya, melakukan hal itu seringkali membutuhkan alokasi memori, yang dapat menyebabkan kegagalannya sendiri.

— supercat

4

Penanganan pengecualian Pokemon (harus menangkap mereka semua!) Tentu tidak selalu buruk. Ketika Anda mengekspos suatu metode kepada klien, terutama pengguna akhir seringkali lebih baik menangkap apa saja dan segalanya daripada membuat aplikasi Anda rusak dan terbakar.

Meskipun mereka harus dihindari di mana pun Anda bisa. Kecuali jika Anda dapat mengambil tindakan spesifik berdasarkan jenis pengecualian, lebih baik tidak menanganinya dan membiarkan pengecualian muncul daripada menelan pengecualian atau menanganinya secara tidak benar.

Lihatlah jawaban SO ini untuk membaca lebih lanjut.

— Tom Squires
sumber

1

Situasi ini (ketika seorang pengembang harus menjadi Pokemon Trainer) muncul ketika Anda membuat seluruh perangkat lunak sendiri: Anda membuat lapisan, koneksi basis data dan GUI pengguna. Aplikasi Anda harus pulih dari situasi seperti kehilangan konektivitas, folder pengguna dihapus, data rusak, dll. Pengguna Akhir tidak suka aplikasi yang macet dan terbakar. Mereka menyukai aplikasi yang dapat bekerja pada komputer yang meledak dan meledak!

— Broken_Window

Saya belum memikirkan hal ini sampai sekarang, tetapi di Pokemon, secara umum diasumsikan bahwa dengan 'menangkap semuanya' Anda ingin masing-masing satu, dan harus menangani penangkapan secara khusus, yang merupakan kebalikan dari penggunaan umum frasa ini. di antara programmer.

— Magus

2

@Magus: Dengan metode seperti LoadDocument(), pada dasarnya tidak mungkin untuk mengidentifikasi semua hal yang mungkin salah, tetapi 99% pengecualian yang dapat dibuang akan berarti "Tidak mungkin untuk menafsirkan konten file dengan nama yang diberikan sebagai sebuah dokumen; atasi itu. " Jika seseorang mencoba untuk membuka sesuatu yang bukan file dokumen yang valid, itu seharusnya tidak merusak aplikasi dan membunuh dokumen terbuka lainnya. Penanganan kesalahan Pokemon dalam kasus seperti itu jelek, tapi saya tidak tahu alternatif yang bagus.

— supercat

@supercat: Saya baru saja membuat poin linguistik. Namun, saya tidak berpikir konten file yang tidak valid terdengar seperti sesuatu yang harus membuang lebih dari satu jenis pengecualian.

— Magus

1

@Magus: Itu bisa melempar segala macam pengecualian - itulah masalahnya. Seringkali sangat sulit untuk mengantisipasi semua jenis pengecualian yang mungkin dilemparkan sebagai konsekuensi dari data yang tidak valid dalam file. Jika seseorang tidak menggunakan penanganan PokeMon, satu risiko memiliki aplikasi mati karena misalnya file yang dimuat memuat string angka yang sangat panjang di tempat yang membutuhkan bilangan bulat 32-bit berformat desimal, dan terjadi pelimpahan numerik pada logika parsing.

— supercat

1

Menangkap pengecualian umum itu buruk karena membuat program Anda dalam keadaan tidak terdefinisi. Anda tidak tahu di mana kesalahan terjadi sehingga Anda tidak tahu apa yang sebenarnya telah dilakukan atau tidak dilakukan oleh program Anda.

Di mana saya akan mengizinkan penangkapan semua adalah saat menutup program. Selama Anda bisa membersihkannya dengan baik. Tidak ada yang menyebalkan seperti program yang Anda tutup yang hanya melempar dialog kesalahan yang tidak melakukan apa-apa selain duduk di sana, tidak pergi dan mencegah komputer Anda untuk menutup.

Dalam lingkungan terdistribusi metode log Anda bisa menjadi bumerang: menangkap pengecualian umum bisa berarti program Anda masih memegang kunci pada file log mencegah pengguna lain membuat log.

— Pieter B
sumber

0

Saya mengerti alasan untuk aturan ini. Tetapi, dalam praktiknya, jika saya ingin mengambil tindakan yang sama terlepas dari pengecualian yang dilontarkan, mengapa saya harus menangani masing-masing secara khusus?

Seperti yang dikatakan orang lain, sangat sulit (jika bukan tidak mungkin) untuk membayangkan beberapa tindakan yang ingin Anda lakukan terlepas dari pengecualian yang dilemparkan. Hanya satu contoh situasi di mana negara program telah rusak dan setiap pengolahan lebih lanjut dapat menyebabkan masalah (ini adalah di belakang alasan Environment.FailFast).

Selanjutnya, jika saya menangani pengecualian tertentu, bagaimana jika kode yang saya panggil perubahan untuk melemparkan pengecualian baru di masa mendatang? Sekarang saya harus mengubah kode saya untuk menangani pengecualian baru itu. Sedangkan jika saya hanya menangkap Pengecualian kode saya tidak perlu berubah.

Untuk kode hobi tidak apa-apa untuk ditangkap Exception, tetapi untuk kode kelas profesional memperkenalkan jenis pengecualian baru harus diperlakukan dengan hormat yang sama seperti perubahan dalam metode tanda tangan, yaitu dianggap sebagai perubahan melanggar. Jika Anda berlangganan sudut pandang ini maka segera jelas bahwa kembali untuk mengubah (atau memverifikasi) kode klien adalah satu-satunya tindakan yang benar.

Misalnya, jika Foo memanggil Bar, dan Foo perlu berhenti memproses terlepas dari jenis pengecualian yang dilemparkan oleh Bar, apakah ada keuntungan untuk menjadi spesifik tentang jenis pengecualian yang saya tangkap?

Tentu, karena Anda tidak akan menangkap hanya pengecualian yang dilemparkan Bar. Juga akan ada pengecualian yang dilemparkan klien Bar atau bahkan runtime selama waktu yang Barada di tumpukan panggilan. Yang ditulis dengan baik Barharus mendefinisikan jenis pengecualiannya sendiri jika perlu sehingga penelepon dapat secara spesifik menangkap pengecualian yang dipancarkan dengan sendirinya.

Jadi bagaimana jika saya ingin mengabaikan setiap pengecualian kecuali OutOfMemoryException?

IMHO ini adalah cara yang salah untuk berpikir tentang penanganan pengecualian. Anda harus beroperasi pada daftar putih (menangkap pengecualian tipe A dan B), bukan pada daftar hitam (menangkap semua pengecualian selain dari X).

— Jon
sumber

Seringkali mungkin untuk menentukan tindakan yang harus dilakukan untuk semua pengecualian yang menunjukkan bahwa operasi yang dicoba gagal tanpa efek samping, dan atau implikasi merugikan tentang keadaan sistem. Misalnya, jika pengguna memilih file dokumen untuk dimuat, sebuah program meneruskan namanya ke metode "buat objek dokumen dengan data dari file disk", dan metode itu gagal karena alasan tertentu aplikasi tidak diantisipasi (tetapi yang memenuhi kriteria di atas), perilaku yang semestinya adalah untuk menampilkan pesan "Tidak dapat memuat dokumen" daripada membuat aplikasi mogok.

— supercat

Sayangnya, tidak ada sarana standar yang digunakan pengecualian untuk menunjukkan hal terpenting yang ingin diketahui kode klien - apakah itu menyiratkan hal buruk tentang keadaan sistem di luar apa yang akan tersirat oleh ketidakmampuan untuk melakukan operasi yang diminta. Jadi, meskipun situasi di mana semua pengecualian harus ditangani jarang terjadi, ada begitu banyak situasi di mana banyak pengecualian harus ditangani dengan cara yang sama, dan tidak ada kriteria yang dipenuhi oleh semua pengecualian seperti itu juga akan dipenuhi oleh beberapa pengecualian langka yang harus ditangani secara berbeda.

— supercat

0

Mungkin . Ada pengecualian untuk setiap aturan, dan tidak ada aturan yang harus diikuti tanpa kritik. Contoh Anda mungkin merupakan salah satu contoh di mana masuk akal untuk menelan semua pengecualian. Misalnya jika Anda ingin menambahkan penelusuran ke sistem produksi kritis, dan Anda ingin memastikan bahwa perubahan yang Anda lakukan tidak mengganggu tugas utama aplikasi.

Namun , Anda harus memikirkan dengan hati-hati tentang kemungkinan alasan kegagalan sebelum Anda memutuskan untuk diam-diam mengabaikan semuanya. Misalnya, bagaimana jika alasan pengecualiannya adalah:

kesalahan pemrograman dalam metode logging yang menyebabkannya selalu melemparkan pengecualian tertentu
jalur yang tidak valid ke file logging di konfigurasi
disk penuh

Tidakkah Anda ingin segera diberitahu bahwa masalah ini ada, sehingga Anda dapat memperbaikinya? Menelan pengecualian berarti Anda tidak pernah tahu ada yang salah.

Beberapa masalah (seperti disk penuh) mungkin juga menyebabkan bagian aplikasi lain gagal - tetapi kegagalan ini tidak dicatat sekarang, jadi Anda tidak pernah tahu!

— JacquesB
sumber

0

Saya ingin membahas ini dari sudut pandang logis daripada perspektif teknis,

Sekarang saya harus mengubah kode saya untuk menangani pengecualian baru itu.

Nah, seseorang harus menanganinya. Itulah idenya. Penulis kode pustaka akan lebih berhati-hati dalam menambahkan tipe pengecualian baru karena karena kemungkinan akan menghancurkan klien, Anda sebaiknya tidak sering menjumpai hal ini.

Pertanyaan Anda pada dasarnya adalah "Bagaimana jika saya tidak peduli apa yang salah? Apakah saya benar-benar harus melalui kerumitan untuk mencari tahu apa itu?"

Inilah bagian kecantikannya: tidak, tidak.

"Jadi, bisakah aku melihat ke arah lain dan membuat sesuatu yang jahat muncul di karpet secara otomatis dan selesai dengan itu?"

Tidak, itu juga bukan cara kerjanya.

Intinya adalah, koleksi perkecualian yang mungkin selalu lebih besar dari koleksi yang Anda harapkan dan tertarik dengan konteks masalah kecil lokal Anda. Anda menangani orang-orang yang Anda antisipasi dan jika sesuatu yang tidak terduga terjadi, Anda menyerahkannya ke penangan tingkat yang lebih tinggi daripada menelannya. Jika Anda tidak peduli dengan pengecualian yang tidak Anda harapkan, Anda bertaruh seseorang akan menumpuk panggilan dan akan menjadi sabotase untuk membunuh pengecualian sebelum mencapai handlernya.

"Tapi ... tapi ... maka salah satu pengecualian lain yang tidak aku pedulikan bisa menyebabkan tugasku gagal!"

Iya. Tetapi mereka akan selalu lebih penting daripada yang ditangani secara lokal. Seperti alarm kebakaran atau bos memberitahu Anda untuk menghentikan apa yang Anda lakukan dan mengambil tugas yang lebih mendesak yang muncul.

— Martin Maat
sumber

-3

Anda harus menangkap pengecualian umum di tingkat teratas dari setiap proses, dan menanganinya dengan melaporkan bug sebaik mungkin dan kemudian menghentikan proses.

Anda seharusnya tidak menangkap pengecualian umum dan mencoba melanjutkan eksekusi.

— ddyer
sumber