Bagikan melalui

Pengecualian dan Performa

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.

Salah satu kekhawatiran umum terkait pengecualian adalah bahwa jika pengecualian digunakan untuk kode yang secara rutin gagal, performa implementasi tidak akan dapat diterima. Ini adalah masalah yang valid. Ketika sebuah komponen melemparkan pengecualian, kinerjanya dapat menjadi jauh lebih lambat. Namun, dimungkinkan untuk mencapai performa yang baik sambil mematuhi pedoman pengecualian yang melarang menggunakan kode kesalahan. Dua pola yang dijelaskan di bagian ini menyarankan cara untuk melakukan ini.

❌ JANGAN gunakan kode kesalahan karena kekhawatiran bahwa pengecualian dapat memengaruhi performa secara negatif.

Untuk meningkatkan performa, dimungkinkan untuk menggunakan Pola Tester-Doer atau Pola Try-Parse, yang dijelaskan di dua bagian berikutnya.

Pola Tester-Doer

Terkadang performa anggota yang melempar pengecualian dapat ditingkatkan dengan memecah anggota menjadi dua. Mari kita lihat metode Add dari antarmuka ICollection<T>.

ICollection<int> numbers = ...
numbers.Add(1);

Metode Add ini melemparkan jika koleksi bersifat baca-saja. Ini bisa menjadi masalah performa dalam skenario di mana panggilan metode diharapkan sering gagal. Salah satu cara untuk mengurangi masalah 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 penguji. Anggota yang digunakan untuk melakukan operasi yang berpotensi menyebabkan kesalahan, metode Add dalam contoh kami, disebut sebagai pelaku.

✔️ PERTIMBANGKAN Pola Tester-Doer untuk anggota yang mungkin melemparkan pengecualian dalam skenario umum untuk menghindari masalah performa yang 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 meminta penyesuaian nama anggota untuk menjadikan kasus uji yang terdefinisi dengan baik menjadi bagian dari semantik anggota. Misalnya, DateTime mendefinisikan Parse metode yang melempar pengecualian jika penguraian string gagal. Ini juga mendefinisikan metode sesuai TryParse yang mencoba mengurai, tetapi mengembalikan nilai false jika penguraian tidak berhasil dan mengembalikan hasil yang berhasil dari penguraian 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 fungsi 'try' dalam cara yang ketat. Jika anggota gagal karena alasan apa pun selain percobaan yang ditentukan dengan baik, anggota masih harus melemparkan pengecualian yang sesuai.

✔️ PERTIMBANGKAN Pola Try-Parse untuk anggota yang berpotensi menimbulkan pengecualian dalam skenario umum agar terhindar dari masalah kinerja yang berkaitan dengan pengecualian.

✔️ DO menggunakan awalan "Coba" dan jenis pengembalian Boolean untuk metode yang mengimplementasikan pola ini.

✔️ DO menyediakan anggota yang melempar pengecualian untuk setiap anggota menggunakan Pola Try-Parse.

© Sebagian 2005, 2009 Microsoft Corporation. Seluruh hak cipta dilindungi.

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.

Lihat juga

  • Last updated on