Granularitas Pengecualian

Saya mengalami perdebatan antara beberapa teman dan saya. Mereka lebih suka pengecualian umum seperti ClientErrorExceptiondan ServerErrorExceptiondengan detail sebagai bidang pengecualian, sedangkan saya lebih suka membuat hal-hal lebih spesifik. Sebagai contoh, saya mungkin memiliki beberapa pengecualian seperti:

BadRequestException
AuthenticationFailureException
ProductNotFoundException

Masing-masing dibangun berdasarkan kode kesalahan yang dikembalikan dari API.

Mengikuti Kelebihan Pengecualian ini tampaknya idiom untuk Jawa. Namun, pendapat teman saya bukanlah hal yang tidak biasa.

Apakah ada cara yang disukai dalam hal keterbacaan kode dan kegunaan API, atau apakah itu benar-benar hanya karena preferensi?

java design exceptions

Halaman yang Anda tautkan kemungkinan adalah jawaban pasti terbaik yang bisa kita dapatkan. Anda meminta pendapat, sungguh. Saya bisa menjawab dengan apa pengalaman dan pendapat saya, tapi itu bukan jawaban yang objektif.

— marstato

@marstato itu adil. Saya kira saya semacam mencari pembenaran di posisi saya. Saya lebih suka menyimpan apa yang orang harapkan di perpustakaan yang saya tulis, daripada mengikuti panduan jika itu berarti itu membuat barang-barang saya lebih mudah digunakan, Anda tahu?

Saya sangat setuju. Saya memiliki kelas pengecualian saya granular juga. Juga, Anda bisa mendefinisikan abstractdan menggeneralisasi kelas pengecualian dengan metode pengambil dan kemudian membuat yang granular memperluas yang umum. Misalnya AuthenticationFaliureException extends ClientErrorException. Dengan cara ini, setiap pengguna dapat memilih bagaimana mereka ingin berurusan dengan pengecualian. Ini lebih banyak bekerja, tentu saja. Namun, ketika menulis aplikasi (bukan perpustakaan), itu adalah situasi IMHO yang berbeda. Dalam hal ini saya tidak akan membuat pengecualian lebih rinci daripada yang Anda butuhkan, demi kesederhanaan.

— marstato

@marstato itulah sebenarnya cara saya mengimplementasikannya sekarang. Aku senang kamu setuju Saya akan membiarkan pertanyaan terbuka pada malam hari, tapi tolong

Jawaban:

Perbedaan utama antara memiliki banyak kelas pengecualian yang berbeda, dan hanya memiliki sedikit, dengan informasi lebih rinci dalam teks kesalahan (misalnya), adalah bahwa banyak kelas pengecualian yang berbeda memungkinkan kode panggilan untuk bereaksi secara berbeda terhadap berbagai jenis kesalahan, sementara memiliki hanya beberapa kelas yang membuatnya lebih mudah untuk menangani semua jenis pengecualian dengan cara yang seragam.

Ini biasanya tradeoff. Pada tingkat tertentu dapat dikurangi dengan menggunakan pewarisan (kelas pengecualian basis umum untuk penelepon yang ingin menangkap & mencatat semuanya secara umum, dan memperoleh pengecualian dari kelas dasar untuk penelepon yang membutuhkan reaksi berbeda), tetapi bahkan yang dapat menghasilkan banyak kerumitan yang tidak perlu jika Anda tidak berhati-hati dan tetap berpegang pada prinsip YAGNI. Jadi pertanyaan panduannya harus ada di sini:

Apakah Anda benar-benar berharap penelepon kode Anda bereaksi berbeda, dengan aliran kontrol yang berbeda, terhadap jenis kesalahan yang berbeda itu?

Tidak ada solusi satu ukuran untuk semua ini, tidak ada "praktik terbaik" braindead yang dapat Anda terapkan masing-masing dan di mana saja. Jawaban atas pertanyaan ini sangat tergantung pada jenis perangkat lunak atau komponen apa yang Anda rancang:

beberapa aplikasi, di mana Anda atau tim memiliki seluruh basis kode di bawah kendali Anda?
atau komponen yang dapat digunakan kembali untuk pihak ketiga, di mana Anda tidak tahu semua penelepon potensial?
aplikasi server yang berjalan lama, di mana berbagai jenis kesalahan tidak boleh menghancurkan seluruh sistem segera dan mungkin memerlukan berbagai jenis mitigasi kesalahan?
proses aplikasi yang berumur pendek di mana cukup jika terjadi kesalahan untuk menampilkan pesan kesalahan kepada pengguna dan kemudian memulai kembali proses?

Jadi semakin Anda tahu tentang penelepon potensial komponen Anda, semakin baik Anda dapat memutuskan tentang tingkat detail yang benar untuk pengecualian Anda.

— Doc Brown
sumber

"Apakah Anda benar-benar berharap penelepon kode Anda bereaksi berbeda, dengan aliran kontrol yang berbeda, terhadap berbagai jenis kesalahan itu?" ini pertanyaan yang bagus untuk ditanyakan. Terima kasih, saya akan mengingat ini.

Ini adalah jawaban yang baik saya pikir, saya hanya akan lebih jauh menekankan perlunya membiarkan aplikasi klien mendorong desain lemparan pengecualian. Bahkan generalisasi yang Anda pikir masuk akal untuk dibangun ke dalam hierarki pengecualian mungkin tidak cocok dengan cara di mana aplikasi klien Anda (jika bukan diri Anda yang menulisnya) mungkin memilih untuk menggeneralisasi handler. Jika Anda memiliki lebih dari satu aplikasi klien dengan kebutuhan yang berbeda, maka tentu saja Anda yang akan menyeimbangkannya.

— magicduncan

Jawabannya tergantung pada tingkat pelaporan kesalahan yang sedang kita bicarakan.

Secara umum saya setuju dengan teman-teman Anda, Anda tidak harus membuatnya lebih rinci daripada yang dibutuhkan untuk menyampaikan penyebab masalah.

Jika ada pengecualian umum yang dikenal untuk referensi null (NullReferenceException), Anda tidak boleh membuat MyObjectIsNullException Anda sendiri. Itu hanya akan menambah lapisan kebingungan bagi penerjemah manusia, hal tambahan untuk dipelajari yang tidak mengklarifikasi apa pun.

Hanya ketika pengecualian Anda adalah khusus yang tidak ada yang ditentukan sebelumnya yang mencakup akar penyebab yang harus Anda buat sendiri.

Namun, Anda tidak harus berhenti di situ. Kesalahan umum dapat terjadi di salah satu komponen Anda dan Anda mungkin ingin menyampaikan bahwa ada masalah di komponen Anda . Jadi tidak hanya apa yang salah tetapi juga di mana. Maka akan lebih tepat untuk membungkus pengecualian pertama dalam MyComponentException. Itu akan memberi Anda yang terbaik dari kedua dunia.

Pertama akan jelas komponen Anda mengalami masalah. Pada tuas yang lebih rendah, penyebab spesifik akan menjadi pengecualian dalam.

— Martin Maat
sumber

Itu adil. Jadi Anda menyarankan agar jangan membuat pengecualian baru ketika yang bagus sudah ada?

@rec Ya, karena semua orang sudah tahu yang sudah ditentukan sebelumnya. Untuk itulah mereka ada di sana.

— Martin Maat