Penggunaan NotImplementedException


15

Apakah dianggap praktik yang buruk untuk membuang NotImplementedExceptionkode yang belum Anda tulis? Mungkin komentar TODO akan dianggap lebih aman?


6
Apa kerugian menggunakan pengecualian seperti itu bagi Anda?
SRKX

@ SKRX Ada risiko pengecualian masuk ke kode produksi dan menyebabkan seluruh blok kode tidak berfungsi. (Belum terjadi pada saya tetapi kita semua memiliki hari libur) Saya pribadi menggunakannya, saya khawatir saya bisa mengabaikan beberapa kelemahan.
Tom Squires

Anehnya, tidak ada tag yang menentukan bahasa apa yang digunakan. Ini tidak berlaku untuk setiap bahasa umum, karena C tidak memiliki pengecualian. Ada ruang untuk tag bahasa di sini, teman.
David Thornley

1
@ Davidvidhorn, pertanyaan awalnya ditandai sebagai C #, jadi saya membaca tag.
svick

@vick: Kupikir itu kemungkinan C #. Terima kasih telah menambahkan tag.
David Thornley

Jawaban:


34

Saya percaya NotImplementedExceptionini sebenarnya praktik yang baik.

Memang, jika Anda lupa untuk menerapkan metode, dan Anda menggunakannya nanti dalam proyek Anda (dan percayalah, itu terjadi), Anda mungkin menghabiskan waktu lama untuk mencari kesalahan yang terjadi selangkah demi selangkah. Jika Anda memiliki pengecualian, program akan berhenti secara langsung, meminta pengecualian (jika Anda menangkap pengecualian, Anda akan menemukannya dengan cepat dengan melihat pengecualian apa yang Anda tangkap).

Saya akan merekomendasikan menggunakan komentar TODO yang NotImplementedException dikombinasikan, dengan cara itu Anda menggabungkan bantuan GUI (dengan tugas-tugas dalam VS) dan keamanan program.

Untuk versi rilis, itu bahkan lebih penting menurut saya, karena dalam kebanyakan kasus Anda lebih suka program Anda crash daripada memiliki program yang tampaknya bekerja dengan baik tetapi menghasilkan hasil yang salah.


6
Jika Anda menggunakan Resharper, itu menunjukkan NotImplementedExceptions dengan cara yang sama seperti komentar TODO. Saya pikir itu fitur yang bagus.
svick

1
Lemparkan beberapa latihan TDD yang bagus dan Anda mendapatkan pemenang
LRE

7

Itu tergantung pada filosofi umum Anda tentang kesalahan dan penanganan kesalahan. Saya adalah tipe pria "kesalahan berat": Saya akan memberikan pengecualian pada petunjuk sekecil apa pun bahwa ada sesuatu yang salah; Saya akan menegaskan semuanya; Jika ada kesalahan, jika sesuatu diharapkan ada di sana, dan itu tidak ada, atau jika ada sesuatu di sana, dan tidak seharusnya, seluruh alam semesta harus berhenti. Suara seruan windows harus berdering tidak enak melalui pengeras suara.

Ada orang lain yang lebih suka tidak terganggu dengan kesalahan. Jadi bagaimana jika kita mengirimkannya ke klien dan seluruh modul laporan hilang karena kita lupa kode itu, dan tidak ada dalam pengujian menyadarinya, karena aplikasi itu terlalu diam tentang hal itu? Lebih baik tidak melakukan apa pun, daripada melemparkan pengecualian ke wajah klien!


Seolah-olah Anda ingin perilaku yang berbeda di Debug dan Rilis, dan pernyataan tidak akan selalu memotongnya. Saya percaya. Kontrak Kode Net dapat dimatikan dalam Rilis.
Ayub

1
Saya kebanyakan menggunakan pernyataan, yang juga dimatikan dalam rilis. Saya memiliki fungsi pernyataan saya sendiri yang mengenai breakpoint dalam debug, melempar pengecualian saat pengujian, atau bahkan tidak mengkompilasi pada rilis.
Mike Nakis

3

Menurut saya itu ide yang bagus. Biasanya saya melihat pengecualian itu dilemparkan oleh kode kerangka yang dihasilkan secara otomatis dari bentuk atau diagram atau sesuatu. Pengecualian mengingatkan saya untuk mengimplementasikan kode, dan memastikan bahwa akan ada kesalahan jika saya mencoba menggunakan fungsi yang telah diatur tetapi tidak pernah sepenuhnya diimplementasikan. Kadang-kadang saya akan mematikannya atau menggantinya dengan sesuatu yang kurang mungkin untuk menghentikan eksekusi (seperti mencetak peringatan ke konsol), tetapi saya menemukan bahwa itu berfungsi untuk saya.

Jika Anda sedang membangun perpustakaan yang orang lain akan menggunakan memiliki pengecualian ini lebih baik daripada alternatifnya, yang akan menjadi pengguna perpustakaan Anda memanggil fungsi dan bertanya-tanya mengapa tidak ada yang terjadi. Tentu saja, masih sangat buruk untuk memiliki pengecualian ini di perpustakaan yang dikirim tetapi lebih baik daripada kegagalan diam, IMO.


1

Saya pikir ini latihan yang bagus. Alternatifnya adalah menyebarkan nilai atau keadaan yang tidak valid, yang akan memengaruhi kode pengujian dan produksi.


1
Tunggu dulu .... maksud Anda, di mana Anda bekerja, kode yang melempar NotImpl akan mencapai QA? Bahkan menjadi produksi?
Steven Evers

3
Tidak, justru kebalikannya: NotImpl adalah kondisi kesalahan / bendera merah yang sangat bagus. Tetapi TODO tidak memiliki nilai semantik dan dapat membuatnya menjadi pengujian atau produksi, diam-diam mengacaukan segalanya. (Saya dapat membayangkan kebijakan menghilangkan TODO dari produksi, tetapi kami tidak memiliki aturan seperti itu.)
Larry OBrien

1

Saya selalu menggunakan NotImplementedException- itu untuk apa, setelah semua.

Ini terkait dengan konsep "gagal cepat": jika kode Anda melempar pengecualian, itu harus ditangkap sebelum pergi ke produksi. Jika produksi, setidaknya klien tahu bahwa perakitan tidak benar .

Jika kode mengembalikan nilai yang tidak berarti atau, untuk voidmetode, tidak mengambil tindakan, maka konsumen kode Anda mungkin berpikir bahwa panggilan itu bermakna ketika tidak. Kemudian, nanti, ketika mereka mendapatkan beberapa kode yang benar, kode mereka mungkin rusak karena itu tergantung pada perilaku yang salah sebelumnya.


0

Proyek macam apa ini? Kerja atau rumah? Di rumah, lakukan apa pun yang Anda inginkan - apa pun yang terbaik mengingatkan Anda bahwa Anda harus menyelesaikan apa pun yang sedang Anda kerjakan.

Di tempat kerja, selesaikan menulisnya.

Saya tidak bisa melihat situasi di mana saya akan checkin kode yang dapat / akan merusak devs lain, QA atau membangun.


Baik keduanya, saya mencoba untuk mematuhi praktik yang baik di rumah juga.
Tom Squires

0

Saya melakukan keduanya saya tetapi harus melakukan autodocing doxygene saya dan kemudian melemparkan pengecualian. Dengan begitu jika orang tidak dapat diganggu ke RTFM setidaknya mereka akan dapat mengetahui mengapa program mereka macet, alih-alih bertanya-tanya mengapa ada fungsi yang dideklarasikan yang tidak mengembalikan nilai logis.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.