Lemparan Pengecualian
Catatan
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 memunculkan pengecualian yang dijelaskan di bagian ini memerlukan definisi yang baik tentang arti kegagalan eksekusi. Kegagalan eksekusi terjadi setiap kali anggota tidak dapat melakukan apa yang dirancang untuk dilakukan (apa yang tersirat dari nama anggota). Misalnya, jika metode OpenFile tidak dapat mengembalikan handel file yang dibuka ke pemanggil, metode tersebut akan dianggap sebagai kegagalan eksekusi.
Sebagian besar pengembang merasa nyaman dengan 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 cara utama melaporkan kesalahan dalam kerangka kerja.
✔️ Laporkan kegagalan eksekusi dengan memunculkan pengecualian.
✔️️ PERTIMBANGKAN untuk menghentikan proses dengan memanggil System.Environment.FailFast (fitur .NET Framework 2.0), bukan memunculkan pengecualian ketika kode Anda menghadapi situasi yang tidak aman untuk eksekusi lebih lanjut.
❌ JANGAN gunakan pengecualian untuk alur kontrol normal, jika memungkinkan.
Kecuali untuk kegagalan sistem dan operasi dengan kondisi persaingan potensial, perancang kerangka kerja harus merancang API sehingga pengguna dapat menulis kode yang tidak membuang pengecualian. Misalnya, Anda dapat menyediakan cara untuk memeriksa prasyarat sebelum memanggil anggota sehingga pengguna dapat menulis kode yang tidak memunculkan pengecualian.
Anggota yang digunakan untuk memeriksa prasyarat anggota lain sering disebut sebagai penguji, dan anggota yang benar-benar melakukan pekerjaan disebut pelaku.
Ada kasus ketika Pola Tester-Doer dapat memiliki kinerja overhead yang tidak dapat diterima. Dalam kasus seperti itu, apa yang disebut Pola Coba-Parse harus dipertimbangkan (lihat Pengecualian dan Performa untuk informasi lebih lanjut).
✔️ ️PERTIMBANGKAN implikasi performa dari kemunculan pengecualian. Tingkat lemparan di atas 100 per detik cenderung berdampak nyata pada performa sebagian besar aplikasi.
✔️ Dokumentasikan semua pengecualian yang dimunculkan oleh anggota yang dapat dipanggil secara publik karena pelanggaran kontrak anggota (bukan kegagalan sistem) dan perlakukan mereka sebagai bagian dari kontrak Anda.
Pengecualian yang merupakan bagian dari kontrak tidak boleh berubah dari satu versi ke versi berikutnya (misalnya, jenis pengecualian tidak boleh berubah, dan pengecualian baru tidak boleh ditambahkan).
❌ JANGAN memiliki anggota publik yang dapat memunculkan atau tidak berdasarkan beberapa opsi.
❌ JANGAN memiliki anggota publik yang mengembalikan pengecualian sebagai nilai kembalian atau parameter out.
Mengembalikan pengecualian dari API publik, bukan memunculkannya guna mengalahkan banyak manfaat pelaporan kesalahan berbasis pengecualian.
✔️ PERTIMBANGKAN untuk menggunakan metode penyusun pengecualian.
Wajar untuk memunculkan pengecualian yang sama dari tempat yang berbeda. Untuk menghindari pemborosan kode, gunakan metode pembantu yang membuat pengecualian dan menginisialisasi propertinya.
Juga, anggota yang memunculkan pengecualian tidak dapat disejajarkan. Memindahkan pernyataan yang muncul ke dalam penyusun mungkin dapat memungkinkan anggota untuk disejajarkan.
❌ JANGAN memunculkan pengecualian dari blok filter pengecualian.
Ketika filter pengecualian memunculkan pengecualian, pengecualian ditangkap oleh CLR, dan filter mengembalikan false. Perilaku ini tidak dapat dibedakan dari filter yang mengeksekusi dan mengembalikan false secara eksplisit, oleh karena itu sangat sulit untuk di-debug.
❌ HINDARI secara eksplisit memunculkan pengecualian dari blok terakhir. Pengecualian yang muncul secara implisit dihasilkan dari metode pemanggilan yang menerima kemunculan.
Portions © 2005, 2009 Microsoft Corporation. Semua hak dilindungi undang-undang.
Dicetak ulang dengan izin dari Pearson Education, Inc. dari Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition oleh Krzysztof Cwalina dan Brad Abrams, diterbitkan 22 Okt 2008 oleh Addison-Wesley Professional sebagai bagian dari Seri Pengembangan Microsoft Windows.