Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Nota
Konten ini dicetak ulang oleh izin Pearson Education, Inc. dari Panduan Desain Kerangka Kerja: Konvensi, Idiom, dan Pola untuk Pustaka .NET yang Dapat Digunakan Kembali, Edisi ke-2. Edisi itu diterbitkan pada tahun 2008, dan buku tersebut telah sepenuhnya direvisi pada edisi ketiga. Beberapa informasi di halaman ini mungkin sudah kedaluarsa.
Pedoman pengelolaan pengecualian yang dijelaskan di bagian ini memerlukan definisi yang baik tentang apa yang dimaksud dengan kegagalan eksekusi. Kegagalan eksekusi terjadi setiap kali anggota tidak dapat melakukan apa yang dirancang untuk dilakukan (apa yang tersirat oleh nama anggota). Misalnya, jika metode OpenFile tidak dapat mengembalikan handle file yang telah dibuka kepada pemanggil, itu akan dianggap sebagai kegagalan eksekusi.
Sebagian besar pengembang telah menjadi nyaman menggunakan pengecualian untuk kesalahan penggunaan seperti pembagian dengan referensi nol atau null. Dalam Kerangka Kerja, pengecualian digunakan untuk semua kondisi kesalahan, termasuk kesalahan eksekusi.
❌ JANGAN mengembalikan kode kesalahan.
Pengecualian adalah sarana utama pelaporan kesalahan dalam kerangka kerja.
✔️ LAPORKAN kegagalan eksekusi dengan melemparkan pengecualian.
✔️ PERTIMBANGKAN untuk mengakhiri proses dengan memanggil System.Environment.FailFast (fitur.NET Framework 2.0) alih-alih melemparkan pengecualian jika kode Anda mengalami situasi di mana tidak aman untuk eksekusi lebih lanjut.
❌ JANGAN gunakan pengecualian untuk alur kontrol normal, jika memungkinkan.
Kecuali untuk kegagalan sistem dan operasi dengan kondisi perlombaan potensial, perancang kerangka kerja harus merancang API sehingga pengguna dapat menulis kode yang tidak melemparkan pengecualian. Misalnya, Anda dapat memberikan cara untuk memeriksa prasyarat sebelum memanggil anggota sehingga pengguna dapat menulis kode yang tidak melemparkan pengecualian.
Anggota yang digunakan untuk memeriksa prasyarat anggota lain sering disebut sebagai penguji, dan anggota yang benar-benar melakukan pekerjaan disebut doer.
Ada kasus ketika Pola Tester-Doer dapat memiliki overhead performa yang tidak dapat diterima. Dalam kasus seperti itu, apa yang disebut Pola Try-Parse harus dipertimbangkan (lihat Pengecualian dan Performa untuk informasi selengkapnya).
✔️ PERTIMBANGKAN implikasi performa dari melempar pengecualian. Tingkat lemparan di atas 100 per detik kemungkinan akan berdampak pada performa sebagian besar aplikasi.
✔️ DO mendokumentasikan semua pengecualian yang dilemparkan oleh anggota yang dapat dipanggil secara publik karena pelanggaran kontrak anggota (bukan kegagalan sistem) dan memperlakukan mereka sebagai bagian dari kontrak Anda.
Pengecualian yang merupakan bagian dari kontrak tidak boleh berubah dari satu versi ke versi berikutnya (yaitu, jenis pengecualian tidak boleh berubah, dan pengecualian baru tidak boleh ditambahkan).
❌ JANGAN memiliki anggota publik yang dapat melempar atau tidak berdasarkan beberapa opsi.
❌ JANGAN memiliki anggota publik yang mengembalikan pengecualian sebagai nilai pengembalian atau sebagai parameter out.
Mengembalikan pengecualian dari API publik alih-alih melemparkannya mengalahkan banyak manfaat pelaporan kesalahan berbasis pengecualian.
✔️ PERTIMBANGKAN menggunakan metode pembangun pengecualian.
Adalah umum untuk melemparkan pengecualian yang sama dari tempat yang berbeda. Untuk menghindari kembung kode, gunakan metode pembantu yang membuat pengecualian dan menginisialisasi propertinya.
Juga, anggota yang melemparkan pengecualian tidak mendapatkan inlined. Memindahkan pernyataan throw ke dalam pembangun mungkin memungkinkan anggota untuk diinlin.
❌ JANGAN melemparkan pengecualian dari blok filter pengecualian.
Ketika filter pengecualian menghasilkan pengecualian, pengecualian ditangkap oleh CLR, dan filter mengembalikan nilai false. Perilaku ini tidak dapat dibedakan dari filter yang mengeksekusi dan mengembalikan false secara eksplisit dan oleh karena itu sangat sulit untuk di-debug.
❌ AVOID secara eksplisit melemparkan pengecualian dari blok akhirnya. Pengecualian yang dilemparkan secara implisit akibat dari pemanggilan metode yang melempar pengecualian dapat diterima.
© Sebagian 2005, 2009 Microsoft Corporation. Hak cipta dilindungi oleh undang-undang
Dicetak ulang oleh izin Pearson Education, Inc. dari Panduan Desain Kerangka Kerja: Konvensi, Idiom, dan Pola untuk Pustaka .NET yang Dapat Digunakan Kembali, Edisi ke-2 oleh Krzysztof Cwalina dan Brad Abrams, diterbitkan 22 Okt 2008 oleh Addison-Wesley Professional sebagai bagian dari Seri Pengembangan Microsoft Windows.