Mengapa "referensi objek tidak disetel ke instance objek" memberi tahu kami objek mana?

Kami meluncurkan sistem, dan terkadang kami mendapatkan pengecualian yang terkenal NullReferenceException dengan pesannya Object reference not set to an instance of an object.

Namun, dalam metode di mana kita memiliki hampir 20 objek, memiliki log yang mengatakan objek adalah null, benar-benar tidak berguna sama sekali. Ini seperti memberi tahu Anda, ketika Anda adalah agen keamanan sebuah seminar, bahwa seorang pria di antara 100 hadirin adalah seorang teroris. Itu benar-benar tidak berguna sama sekali bagi Anda. Anda harus mendapatkan informasi lebih lanjut, jika Anda ingin mendeteksi pria mana yang merupakan pria yang mengancam.

Demikian juga, jika kita ingin menghapus bug, kita perlu tahu objek mana yang null.

Sekarang, sesuatu telah terobsesi dengan pikiran saya selama beberapa bulan, dan itu adalah:

Mengapa .NET tidak memberi kami nama, atau setidaknya jenis referensi objek, yang nol?. Tidak bisakah ia memahami tipe dari refleksi atau sumber lain?

Juga, apa praktik terbaik untuk memahami objek mana yang nol? Haruskah kita selalu menguji nullability objek dalam konteks ini secara manual dan mencatat hasilnya? Apakah ada cara yang lebih baik?

Pembaruan: Pengecualian The system cannot find the file specifiedmemiliki sifat yang sama. Anda tidak dapat menemukan file mana, sampai Anda melampirkan ke proses dan debug. Saya kira jenis pengecualian ini bisa menjadi lebih cerdas. Bukankah lebih baik jika .NET dapat memberi tahu kami c:\temp.txt doesn't exist.alih-alih pesan umum itu? Sebagai pengembang, saya memilih ya.

Pada NullReferenceExceptiondasarnya memberitahu Anda: Anda salah melakukannya. Tidak lebih, tidak kurang. Sebaliknya, itu bukan alat debugging lengkap. Dalam hal ini saya katakan Anda salah melakukannya karena keduanya

• ada NullReferenceException
• Anda tidak mencegahnya dengan cara Anda tahu mengapa / di mana itu terjadi
• dan mungkin juga: sebuah metode yang membutuhkan 20 objek sepertinya sedikit salah

Saya penggemar berat memeriksa semuanya sebelum segala sesuatunya mulai salah, dan memberikan informasi yang baik kepada pengembang. Singkatnya: tulis cek menggunakan ArgumentNullExceptiondan suka dan tulis nama sendiri. Berikut ini contohnya:

void Method(string a, SomeObject b)
{
    if (a == null) throw ArgumentNullException("a");
    if (b == null) throw ArgumentNullException("b");

    // See how nice this is, and what peace of mind this provides? As long as
    // nothing modifies a or b you can use them here and be 100% sure they're not
    // null. Should they be when entering the method, at least you know which one
    // is null.
    var c = FetchSomeObject();
    if(c == null)
    {
        throw InvalidOperationException("Fetching B failed!!");
    }

    // etc.
}

Anda juga dapat melihat Kontrak Kode , memiliki kebiasaan tetapi berfungsi dengan baik dan menghemat beberapa mengetik.

Itu benar-benar harus menunjukkan dengan tepat apa yang Anda coba panggil. Itu seperti mengatakan "Ada masalah. Kamu harus memperbaikinya. Aku tahu apa itu. Aku tidak akan memberitahumu. Kamu mencari tahu" Agak seperti setengah jawaban pada Stack Overflow ini, ironisnya.

Jadi seberapa bermanfaatkah itu, misalnya, jika Anda mendapatkan ini ...

Object reference (HttpContext.Current) not set to instance of an object

...? Harus masuk ke dalam kode, melangkah melaluinya, dan mencari tahu bahwa hal yang Anda coba panggil nullbaik-baik saja, tetapi mengapa tidak memberi kami sedikit bantuan?

Saya setuju bahwa biasanya berguna untuk menelusuri kode untuk mendapatkan jawaban (karena Anda mungkin akan menemukan lebih banyak), tetapi sering kali banyak waktu dan frustrasi akan disimpan jika NullReferenceExceptionteksnya lebih seperti contoh di atas.

Katakan saja.

Log Anda harus menyertakan jejak stack - yang biasanya memberi Anda petunjuk tentang baris mana dalam metode yang memiliki masalah. Anda mungkin perlu membuat versi rilis Anda menyertakan simbol PDB sehingga Anda memiliki ide untuk baris mana kesalahan tersebut aktif.

Memang, itu tidak akan membantu Anda dalam hal ini:

Foo.Bar.Baz.DoSomething()

Prinsip tell don't ask dapat membantu menghindari kode tersebut.

Mengenai mengapa informasi tersebut tidak termasuk, saya tidak yakin - Saya menduga bahwa setidaknya dalam membangun debug, jika mereka benar-benar ingin, mereka bisa mengetahuinya. Mengambil crash dump dan membuka di WinDBG dapat membantu.

Pengecualian telah dibuat sebagai alat untuk menandai kondisi non-fatal yang luar biasa di rantai panggilan. Artinya, mereka tidak dirancang sebagai alat debugging.

Jika pengecualian null-pointer adalah alat debugging, itu akan membatalkan eksekusi program tepat di tempat, memungkinkan debugger untuk terhubung, mengarahkannya tepat di garis yang memberatkan. Ini akan memberi programmer semua informasi konteks yang tersedia. (Yang cukup banyak seperti Segfault karena akses pointer nol tidak dalam C, meskipun agak kasar.)

Namun, pengecualian null-pointer dirancang sebagai kondisi runtime yang valid yang dapat dibuang dan ditangkap dalam aliran program normal. Konsekuensinya, pertimbangan kinerja perlu diperhitungkan. Dan setiap kustomisasi pesan pengecualian membutuhkan objek string yang dibuat, digabungkan, dan dihancurkan saat runtime. Dengan demikian, pesan statis tidak dapat disangkal lebih cepat.

Saya tidak mengatakan bahwa runtime tidak dapat diprogram dengan cara yang akan menghasilkan nama referensi yang memberatkan. Itu bisa dilakukan. Itu hanya akan membuat pengecualian lebih lambat dari mereka. Jika ada yang cukup peduli, fitur semacam itu bahkan dapat dibuat dapat dipindah-pindah, sehingga tidak akan memperlambat kode produksi, tetapi memungkinkan proses debug yang lebih mudah; tetapi karena alasan tertentu tampaknya tidak ada yang cukup peduli.

Cromulent mengenai kuku di kepala saya pikir, namun ada poin yang jelas juga bahwa jika Anda mendapatkan NullReferenceExceptionAnda memiliki variabel yang tidak diinisialisasi. Argumen bahwa Anda memiliki sekitar 20 objek yang diteruskan ke dalam metode tidak dapat dikatakan sebagai mitigasi: sebagai pencipta sejumlah kode Anda harus bertanggung jawab atas tindakannya, yang mencakup kepatuhannya pada seluruh basis kode, karena pemanfaatan variabel yang tepat dan benar, dll.

itu berat, membosankan dan kadang-kadang membosankan, tetapi hasilnya pada akhirnya sepadan: banyak kali ketika saya harus menjelajah melalui file log dengan berat beberapa gigabyte, dan mereka hampir selalu membantu. Namun sebelum Anda sampai ke tahap itu, debugger dapat membantu Anda, dan sebelum tahap perencanaan yang baik akan menghemat banyak rasa sakit (dan saya tidak bermaksud pendekatan rekayasa penuh untuk Anda solusi kode baik: sketsa sederhana dan beberapa catatan dapat dan akan lebih baik daripada tidak sama sekali).

Berkenaan dengan Object reference not set to an instance of an objectkode tidak dapat menebak nilai-nilai yang kita sukai: itu adalah tugas kami sebagai programmer, dan itu berarti Anda telah melewati variabel yang tidak diinisialisasi.

Pelajari cara menggunakan debugger. Ini persis seperti apa itu dirancang untuk. Tetapkan titik istirahat pada metode yang dimaksud dan pergilah.

Cukup langkah melalui kode Anda dan lihat apa nilai semua variabel Anda pada titik-titik tertentu.

Sunting: Terus terang saya terkejut bahwa belum ada orang lain yang menyebutkan menggunakan debugger.

Jika Anda ingin menggunakan jawaban @ stijn dan memberikan cek nol pada kode Anda, cuplikan kode ini akan membantu. Berikut ini beberapa info tentang cuplikan kode . Setelah Anda mengatur ini, cukup ketik argnull, tekan tab dua kali, dan kemudian isi yang kosong.

<CodeSnippet Format="1.0.0">
  <Header>
    <Title>EnsureArgNotNull</Title>
    <Shortcut>argnull</Shortcut>
  </Header>
  <Snippet>
    <Declarations>
      <Literal>
        <ID>argument</ID>
        <ToolTip>The name of the argument that shouldn't be null</ToolTip>
        <Default>arg</Default>
      </Literal>
    </Declarations>
    <Code Language="CSharp">
      <![CDATA[if ($argument$ == null) throw new ArgumentNullException("$argument$");$end$]]>
    </Code>
  </Snippet>
</CodeSnippet>