Pengecualian dan Performa
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.
Salah satu perhatian yang biasa terjadi terkait dengan pengecualian adalah jika pengecualian digunakan untuk kode yang gagal secara rutin, performa implementasi akan tidak dapat diterima. Ini adalah masalah yang valid. Ketika anggota melemparkan pengecualian, performanya dapat lebih lambat. Namun, performa yang bagus dapat dicapai saat mematuhi panduan pengecualian dengan teliti yang tidak mengizinkan penggunaan kode galat. Dua pola yang dijelaskan dalam bagian ini menyarankan cara untuk melakukannya.
❌ JANGAN gunakan kode kesalahan karena pengecualian berpotensi dapat memengaruhi performa secara negatif.
Untuk meningkatkan performa, Pola Tester-Doer atau Pola Try-Parse dapat digunakan, seperti yang dijelaskan dalam dua bagian berikutnya.
Pola Tester-Doer
Performa anggota yang melempar pengecualian terkadang dapat ditingkatkan dengan memecah anggota menjadi dua. Mari kita lihat metode Add antarmuka ICollection<T>.
ICollection<int> numbers = ...
numbers.Add(1);
Metode Add melemparkan jika koleksi bersifat baca-saja. Ini bisa menjadi masalah performa dalam skenario ketika panggilan metode diharapkan sering gagal. Salah satu cara untuk mengurangi masalah ini adalah dengan menguji apakah koleksi dapat ditulis sebelum mencoba menambahkan nilai.
ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
numbers.Add(1);
}
Anggota yang digunakan untuk menguji kondisi, yang dalam contoh kami adalah properti IsReadOnly, disebut sebagai tester. Anggota yang digunakan untuk melakukan operasi yang berpotensi melempar, dalam contoh kami metode Add, disebut sebagai doer.
✔️ PERTIMBANGKAN Pola Tester-Doer untuk anggota yang mungkin melemparkan pengecualian dalam skenario umum untuk menghindari masalah performa terkait dengan pengecualian.
Pola Try-Parse
Untuk API yang sangat sensitif terhadap performa, pola yang bahkan lebih cepat daripada Pola Tester-Doer yang dijelaskan di bagian sebelumnya harus digunakan. Pola ini memanggil untuk menyesuaikan nama anggota untuk membuat kasus pengujian yang terdefinisi dengan baik sebagai bagian dari semantik anggota. Misalnya, DateTime mendefinisikan metode Parse yang melemparkan pengecualian jika penguraian string gagal. Hal ini juga mendefinisikan metode TryParse yang sesuai yang mencoba mengurai, tetapi mengembalikan false jika penguraian tidak berhasil dan mengembalikan hasil penguraian yang berhasil menggunakan parameter out.
public struct DateTime
{
public static DateTime Parse(string dateTime)
{
...
}
public static bool TryParse(string dateTime, out DateTime result)
{
...
}
}
Saat menggunakan pola ini, penting untuk menentukan fungsionalitas try dalam istilah yang ketat. Jika gagal karena alasan selain try yang ditentukan dengan baik, anggota masih harus melemparkan pengecualian yang sesuai.
✔️ PERTIMBANGKAN Pola Tester-Doer untuk anggota yang mungkin melemparkan pengecualian dalam skenario umum untuk menghindari masalah performa terkait dengan pengecualian.
✔️ GUNAKAN awalan "Try" dan jenis kembali Boolean untuk metode yang mengimplementasikan pola ini.
✔️ SEDIAKAN anggota pelempar pengecualian untuk setiap anggota menggunakan Pola Try-Parse.
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.