Pengecualian apa yang harus diberikan untuk parameter yang tidak valid atau tidak terduga di .NET?

Apa jenis pengecualian yang harus dilemparkan untuk parameter yang tidak valid atau tidak terduga di .NET? Kapan saya memilih satu dan bukan yang lain?

Mengikuti:

Pengecualian mana yang akan Anda gunakan jika Anda memiliki fungsi yang mengharapkan bilangan bulat sesuai dengan bulan dan Anda melewati '42'? Apakah ini termasuk dalam kategori "di luar jangkauan" walaupun itu bukan koleksi?

Saya ingin menggunakan: ArgumentException, ArgumentNullException, dan ArgumentOutOfRangeException.

• ArgumentException - Ada yang salah dengan argumen itu.
• ArgumentNullException - Argumen adalah nol.
• ArgumentOutOfRangeException - Saya tidak terlalu sering menggunakan ini, tetapi penggunaan umum adalah pengindeksan ke koleksi, dan memberikan indeks yang besar.

Ada opsi lain juga, yang tidak terlalu fokus pada argumen itu sendiri, tetapi menilai panggilan secara keseluruhan:

• InvalidOperationException- Argumennya mungkin OK, tetapi tidak dalam keadaan objek saat ini. ^{_{Kredit jatuh ke STW (sebelumnya Yoooder). Pilih jawabannya juga.}}
• NotSupportedException- Argumen yang disahkan valid, tetapi tidak didukung dalam implementasi ini. Bayangkan klien FTP, dan Anda memberikan perintah bahwa klien tidak mendukung.

Caranya adalah dengan melemparkan pengecualian yang paling baik mengungkapkan mengapa metode ini tidak dapat disebut apa adanya. Idealnya, pengecualian harus dirinci tentang apa yang salah, mengapa itu salah, dan bagaimana cara memperbaikinya.

Saya suka ketika pesan kesalahan menunjuk ke bantuan, dokumentasi, atau sumber daya lainnya. Misalnya, Microsoft melakukan langkah pertama yang baik dengan artikel KB mereka, misalnya "Mengapa saya menerima pesan kesalahan" Operasi dibatalkan "ketika saya mengunjungi halaman Web di Internet Explorer?" . Ketika Anda menemukan kesalahan, mereka mengarahkan Anda ke artikel KB di pesan kesalahan. Yang tidak mereka lakukan dengan baik adalah bahwa mereka tidak memberi tahu Anda, mengapa secara khusus itu gagal.

^{_{Terima kasih kepada STW (ex Yoooder) lagi untuk komentarnya.}}

Menanggapi tindak lanjut Anda, saya akan melempar ArgumentOutOfRangeException. Lihatlah apa yang dikatakan MSDN tentang pengecualian ini:

ArgumentOutOfRangeExceptiondilemparkan ketika metode dipanggil dan setidaknya salah satu argumen yang diteruskan ke metode ini bukan referensi nol ( Nothingdalam Visual Basic) dan tidak mengandung nilai yang valid.

Jadi, dalam hal ini, Anda memberikan nilai, tetapi itu bukan nilai yang valid, karena rentang Anda adalah 1–12. Namun, cara Anda mendokumentasikannya memperjelas, apa yang dilemparkan API Anda. Karena walaupun saya mungkin mengatakan ArgumentOutOfRangeException, pengembang lain mungkin mengatakan ArgumentException. Permudah dan dokumentasikan perilakunya.

Saya memilih jawaban Josh , tetapi ingin menambahkan satu lagi ke daftar:

System.InvalidOperationException harus dilemparkan jika argumen tersebut valid, tetapi objek berada dalam keadaan di mana argumen tidak boleh digunakan.

Pembaruan Diambil dari MSDN:

InvalidOperationException digunakan dalam kasus ketika kegagalan untuk memanggil metode disebabkan oleh alasan selain argumen yang tidak valid.

Katakanlah objek Anda memiliki metode PerformAction (enmSomeAction action), enmSomeActions yang valid adalah Buka dan Tutup. Jika Anda memanggil PerformAction (enmSomeAction.Open) dua kali berturut-turut maka panggilan kedua harus melempar InvalidOperationException (karena arugment valid, tetapi tidak untuk keadaan kontrol saat ini)

Karena Anda sudah melakukan hal yang benar dengan pemrograman defensif saya punya satu pengecualian lain untuk menyebutkan adalah ObjectDisposedException. Jika objek Anda mengimplementasikan IDisposable maka Anda harus selalu memiliki variabel kelas yang melacak keadaan dibuang; jika objek Anda telah dibuang dan sebuah metode dipanggil, Anda harus meningkatkan ObjectDisposedException:

public void SomeMethod()
{
    If (m_Disposed) {
          throw new ObjectDisposedException("Object has been disposed")
     }
    // ... Normal execution code
}

Pembaruan: Untuk menjawab tindak lanjut Anda: Ini adalah situasi yang agak ambigu, dan dibuat sedikit lebih rumit oleh tipe data generik (bukan dalam pengertian .NET Generics) yang digunakan untuk mewakili sekumpulan data tertentu; enum atau objek yang sangat diketik lainnya akan lebih cocok - tetapi kita tidak selalu memiliki kontrol itu.

Saya pribadi akan condong ke ArgumentOutOfRangeException dan memberikan pesan yang menunjukkan nilai yang valid adalah 1-12. Alasan saya adalah bahwa ketika Anda berbicara tentang bulan, dengan asumsi semua representasi bilangan bulat bulan valid, maka Anda mengharapkan nilai dalam kisaran 1-12. Jika hanya bulan-bulan tertentu (seperti bulan yang memiliki 31 hari) yang valid maka Anda tidak akan berurusan dengan Range per-se dan saya akan membuang ArgumentException umum yang menunjukkan nilai-nilai yang valid, dan saya juga akan mendokumentasikannya dalam komentar metode.

Bergantung pada nilai aktual dan pengecualian apa yang paling cocok:

• ArgumentException (ada yang salah dengan nilainya)

• ArgumentNullException (argumennya adalah null sementara ini tidak diperbolehkan)

• ArgumentOutOfRangeException (argumen memiliki nilai di luar rentang yang valid)

Jika ini tidak cukup tepat, turunkan saja kelas pengecualian Anda sendiri ArgumentException.

Jawaban Yoooder mencerahkan saya. Input tidak valid jika tidak valid kapan saja, sedangkan input tidak terduga jika tidak valid untuk kondisi sistem saat ini. Jadi dalam kasus selanjutnya, an InvalidOperationExceptionadalah pilihan yang masuk akal.

pengecualian argumen.

• System.ArgumentException
• System.ArgumentNullException
• System.ArgumentOutOfRangeException

ArgumentException :

ArgumentException dilemparkan ketika suatu metode dipanggil dan setidaknya satu dari argumen yang dilewati tidak memenuhi spesifikasi parameter dari metode yang dipanggil. Semua instance ArgumentException harus membawa pesan kesalahan yang bermakna yang menguraikan argumen yang tidak valid, serta kisaran nilai yang diharapkan untuk argumen.

Beberapa subclass juga ada untuk jenis ketidakabsahan tertentu. Tautan ini memiliki ringkasan subtipe dan kapan harus berlaku.

Jawaban singkat:
Baik

Jawaban yang lebih panjang:
menggunakan Argumen * Pengecualian (kecuali di perpustakaan yang merupakan produk di atasnya, seperti perpustakaan komponen) adalah bau. Pengecualian adalah untuk menangani situasi luar biasa, bukan bug, dan bukan kekurangan pengguna (yaitu konsumen API).

Jawaban terlama:
Melontarkan pengecualian untuk argumen yang tidak valid adalah kasar, kecuali Anda menulis perpustakaan.
Saya lebih suka menggunakan pernyataan, karena dua (atau lebih) alasan:

• Pernyataan tidak perlu diuji, sementara pernyataan melemparkan, dan pengujian terhadap ArgumentNullException terlihat konyol (coba saja).
• Pernyataan lebih baik mengkomunikasikan tujuan penggunaan unit, dan lebih dekat menjadi dokumentasi yang dapat dieksekusi daripada spesifikasi perilaku kelas.
• Anda bisa mengubah perilaku pelanggaran asersi. Misalnya dalam kompilasi debug, kotak pesan baik-baik saja, sehingga QA Anda akan langsung menerimanya dengan Anda (Anda juga mendapatkan IDE Anda melanggar pada garis di mana itu terjadi), sedangkan dalam unit test Anda dapat menunjukkan kegagalan pernyataan sebagai kegagalan pengujian .

Berikut ini adalah bagaimana penanganan pengecualian null (menjadi sarkastik, jelas):

try {
    library.Method(null);
}
catch (ArgumentNullException e) {
    // retry with real argument this time
    library.Method(realArgument);
}

Pengecualian harus digunakan ketika situasi diharapkan tetapi luar biasa (terjadi hal-hal yang di luar kendali konsumen, seperti kegagalan IO). Argumen * Pengecualian adalah indikasi bug dan akan (pendapat saya) ditangani dengan tes dan dibantu dengan Debug.

BTW: Dalam kasus khusus ini, Anda bisa menggunakan tipe Bulan, bukan int. C # gagal ketika harus mengetikkan safety (Aspect # rulez!) Tetapi terkadang Anda dapat mencegah (atau menangkap pada waktu kompilasi) semua bug tersebut secara bersamaan.

Dan ya, MicroSoft salah tentang itu.

Ada ArgumentException standar yang bisa Anda gunakan, atau Anda bisa membuat subkelas dan membuatnya sendiri. Ada beberapa kelas ArgumentException tertentu:

http://msdn.microsoft.com/en-us/library/system.argumentexception(VS.71).aspx

Mana yang paling berhasil.