Mengapa secara eksplisit melempar NullPointerException daripada membiarkannya terjadi secara alami?

Saat membaca kode sumber JDK, saya merasa umum bahwa penulis akan memeriksa parameter jika mereka nol dan kemudian melemparkan NullPointerException () baru secara manual. Mengapa mereka melakukannya? Saya pikir tidak perlu melakukannya karena itu akan membuang NullPointerException () baru ketika memanggil metode apa pun. (Berikut adalah beberapa kode sumber HashMap, misalnya :)

public V computeIfPresent(K key,
                          BiFunction<? super K, ? super V, ? extends V> remappingFunction) {
    if (remappingFunction == null)
        throw new NullPointerException();
    Node<K,V> e; V oldValue;
    int hash = hash(key);
    if ((e = getNode(hash, key)) != null &&
        (oldValue = e.value) != null) {
        V v = remappingFunction.apply(key, oldValue);
        if (v != null) {
            e.value = v;
            afterNodeAccess(e);
            return v;
        }
        else
            removeNode(hash, key, null, false, true);
    }
    return null;
}

Ada sejumlah alasan yang muncul di benak, beberapa terkait erat:

Gagal-cepat: Jika gagal, lebih baik cepat gagal daripada nanti. Ini memungkinkan masalah untuk ditangkap lebih dekat ke sumbernya, membuatnya lebih mudah untuk diidentifikasi dan pulih. Ini juga menghindari pemborosan siklus CPU pada kode yang pasti gagal.

Maksud: Melempar pengecualian secara eksplisit membuat jelas bagi pengelola bahwa kesalahan itu ada dengan sengaja dan penulis menyadari konsekuensinya.

Konsistensi: Jika kesalahan dibiarkan terjadi secara alami, itu mungkin tidak terjadi di setiap skenario. Jika tidak ada pemetaan yang ditemukan, misalnya, remappingFunctiontidak akan pernah digunakan dan pengecualian tidak akan dibuang. Memvalidasi input terlebih dahulu memungkinkan perilaku yang lebih deterministik dan dokumentasi yang lebih jelas .

Stabilitas: Kode berkembang seiring waktu. Kode yang mengalami pengecualian secara alami mungkin, setelah sedikit refactoring, berhenti melakukannya, atau melakukannya dalam keadaan yang berbeda. Melemparkannya secara eksplisit membuat perilaku cenderung berubah secara tidak sengaja.

Ini untuk kejelasan, konsistensi, dan untuk mencegah pekerjaan tambahan yang tidak perlu dilakukan.

Pertimbangkan apa yang akan terjadi jika tidak ada klausa penjaga di bagian atas metode ini. Itu akan selalu memanggil hash(key)dan getNode(hash, key)bahkan ketika nulltelah dilewati untuk remappingFunctionsebelum NPE dilemparkan.

Lebih buruk lagi, jika ifkondisinya falsemaka kita mengambil elsecabang, yang tidak menggunakan remappingFunctionsama sekali, yang berarti metode tidak selalu membuang NPE ketika a nulldilewatkan; apakah itu tergantung pada kondisi peta.

Kedua skenario itu buruk. Jika nullbukan nilai yang valid untuk remappingFunctionmetode ini harus secara konsisten melempar pengecualian terlepas dari keadaan internal objek pada saat panggilan, dan harus melakukannya tanpa melakukan pekerjaan yang tidak perlu yang tidak ada gunanya mengingat bahwa itu hanya akan melempar. Akhirnya, itu adalah prinsip yang baik dari kode yang bersih dan jelas untuk memiliki penjaga di depan sehingga siapa pun yang meninjau kode sumber dapat dengan mudah melihat bahwa itu akan melakukannya.

Bahkan jika pengecualian saat ini dilemparkan oleh setiap cabang kode, ada kemungkinan bahwa revisi kode di masa depan akan mengubahnya. Melakukan pemeriksaan di awal memastikan pasti akan dilakukan.

Selain alasan yang tercantum oleh jawaban sempurna @ shmosel ...

Kinerja: Mungkin ada / telah ada manfaat kinerja (pada beberapa JVM) untuk melempar NPE secara eksplisit daripada membiarkan JVM melakukannya.

Itu tergantung pada strategi yang Java interpreter dan JIT compiler ambil untuk mendeteksi dereferencing dari null pointer. Salah satu strategi adalah untuk tidak menguji null, tetapi malah menjebak SIGSEGV yang terjadi ketika instruksi mencoba mengakses alamat 0. Ini adalah pendekatan tercepat dalam kasus di mana referensi selalu valid, tetapi mahal dalam kasus NPE.

Tes eksplisit untuk nulldalam kode akan menghindari kinerja SIGSEGV hit dalam skenario di mana NPE sering terjadi.

(Saya ragu bahwa ini akan menjadi optimasi mikro yang bermanfaat dalam JVM modern, tetapi bisa saja di masa lalu.)

Kompatibilitas: Kemungkinan alasan tidak ada pesan dalam pengecualian adalah untuk kompatibilitas dengan NPE yang dilemparkan oleh JVM itu sendiri. Dalam implementasi Java yang patuh, NPE yang dilempar oleh JVM memiliki nullpesan. (Android Java berbeda.)

Terlepas dari apa yang orang lain tunjukkan, ada baiknya memperhatikan peran kebaktian di sini. Dalam C #, misalnya, Anda juga memiliki konvensi yang sama untuk secara eksplisit meningkatkan pengecualian dalam kasus-kasus seperti ini, tetapi secara khusus ArgumentNullException, yang agak lebih spesifik. (C # konvensi adalah bahwa NullReferenceException selalu merupakan bug dari beberapa jenis - cukup sederhana, seharusnya tidak pernah terjadi dalam kode produksi; diberikan, ArgumentNullExceptionbiasanya tidak juga, tetapi bisa menjadi bug lebih sepanjang garis "Anda tidak mengerti bagaimana menggunakan perpustakaan dengan benar "jenis bug).

Jadi, pada dasarnya, dalam C # NullReferenceExceptionberarti bahwa program Anda benar-benar mencoba menggunakannya, sedangkan ArgumentNullExceptionitu berarti bahwa ia mengakui bahwa nilainya salah dan bahkan tidak repot-repot untuk mencoba menggunakannya. Implikasinya sebenarnya bisa berbeda (tergantung pada keadaan) karena ArgumentNullExceptionberarti bahwa metode yang dimaksud belum memiliki efek samping (karena gagal dalam prasyarat metode).

Secara kebetulan, jika Anda menaikkan sesuatu seperti ArgumentNullExceptionatau IllegalArgumentException, itulah bagian dari titik melakukan pemeriksaan: Anda menginginkan pengecualian yang berbeda dari yang biasanya Anda dapatkan.

Either way, secara eksplisit meningkatkan pengecualian memperkuat praktik baik menjadi eksplisit tentang pra-kondisi metode Anda dan argumen yang diharapkan, yang membuat kode lebih mudah dibaca, digunakan, dan dipelihara. Jika Anda tidak secara eksplisit memeriksa null, saya tidak tahu apakah itu karena Anda berpikir bahwa tidak ada yang akan pernah melewati nullargumen, Anda tetap menghitungnya untuk membuang pengecualian, atau Anda hanya lupa untuk memeriksa itu.

Sehingga Anda akan mendapatkan pengecualian begitu Anda melakukan kesalahan, daripada nanti ketika Anda menggunakan peta dan tidak akan mengerti mengapa itu terjadi.

Ini mengubah kondisi kesalahan yang tampaknya tidak menentu menjadi pelanggaran kontrak yang jelas: Fungsi ini memiliki beberapa prasyarat untuk bekerja dengan benar, sehingga memeriksa mereka sebelumnya, memaksa mereka untuk dipenuhi.

Efeknya adalah, Anda tidak perlu melakukan debug computeIfPresent()ketika Anda mendapatkan pengecualian darinya. Setelah Anda melihat bahwa pengecualian tersebut berasal dari pemeriksaan prasyarat, Anda tahu bahwa Anda memanggil fungsi dengan argumen ilegal. Jika cek tidak ada di sana, Anda harus mengecualikan kemungkinan ada beberapa bug di dalamnya computeIfPresent()yang mengarah ke pengecualian yang dilemparkan.

Jelas, melempar NullPointerExceptionobat generik adalah pilihan yang sangat buruk, karena tidak menandakan adanya pelanggaran kontrak. IllegalArgumentExceptionakan menjadi pilihan yang lebih baik.

Sidenote:
Saya tidak tahu apakah Java mengizinkan ini (saya ragu), tetapi programmer C / C ++ menggunakan assert()dalam kasus ini, yang secara signifikan lebih baik untuk debugging: Ini memberitahu program untuk crash segera dan sekeras mungkin harus disediakan kondisi bernilai false. Jadi, jika Anda berlari

void MyClass_foo(MyClass* me, int (*someFunction)(int)) {
    assert(me);
    assert(someFunction);

    ...
}

di bawah debugger, dan sesuatu masuk NULLke salah satu argumen, program akan berhenti tepat di baris yang mengatakan argumen mana NULL, dan Anda akan dapat memeriksa semua variabel lokal dari seluruh tumpukan panggilan di waktu luang.

Itu karena itu mungkin tidak terjadi secara alami. Mari kita lihat sepotong kode seperti ini:

bool isUserAMoron(User user) {
    Connection c = UnstableDatabase.getConnection();
    if (user.name == "Moron") { 
      // In this case we don't need to connect to DB
      return true;
    } else {
      return c.makeMoronishCheck(user.id);
    }
}

(tentu saja ada banyak masalah dalam sampel ini tentang kualitas kode. Maaf malas membayangkan sampel sempurna)

Situasi ketika ctidak akan benar-benar digunakan dan NullPointerExceptiontidak akan dibuang bahkan jika c == nullmemungkinkan.

Dalam situasi yang lebih rumit, menjadi sangat tidak mudah untuk memburu kasus seperti itu. Inilah sebabnya mengapa pemeriksaan umum seperti if (c == null) throw new NullPointerException()lebih baik.

Dimaksudkan untuk melindungi kerusakan lebih lanjut, atau memasuki kondisi yang tidak konsisten.

Terlepas dari semua jawaban bagus lainnya di sini, saya juga ingin menambahkan beberapa kasus.

Anda dapat menambahkan pesan jika Anda membuat pengecualian Anda sendiri

Jika Anda melempar sendiri, NullPointerExceptionAnda dapat menambahkan pesan (yang memang seharusnya!)

Pesan default adalah nulldari new NullPointerException()dan semua metode yang menggunakannya, misalnya Objects.requireNonNull. Jika Anda mencetak nol itu bahkan dapat menerjemahkan ke string kosong ...

Agak pendek dan tidak informatif ...

Jejak tumpukan akan memberikan banyak informasi, tetapi bagi pengguna untuk mengetahui apa yang nol mereka harus menggali kode dan melihat baris yang tepat.

Sekarang bayangkan NPE dibungkus dan dikirim melalui internet, misalnya sebagai pesan dalam kesalahan layanan web, mungkin antara departemen yang berbeda atau bahkan organisasi. Skenario terburuk, tidak ada yang tahu apa nullkepanjangan dari ...

Panggilan metode berantai akan membuat Anda menebak

Pengecualian hanya akan memberi tahu Anda pada baris apa pengecualian itu terjadi. Pertimbangkan baris berikut:

repository.getService(someObject.someMethod());

Jika Anda mendapatkan NPE dan menunjuk pada baris ini, yang mana dari repositorydan someObjectnol?

Sebaliknya, memeriksa variabel-variabel ini ketika Anda mendapatkannya setidaknya akan menunjuk ke baris di mana mereka diharapkan satu-satunya variabel yang ditangani. Dan, seperti yang disebutkan sebelumnya, bahkan lebih baik jika pesan kesalahan Anda berisi nama variabel atau sejenisnya.

Kesalahan saat memproses banyak input harus memberikan informasi pengenal

Bayangkan program Anda sedang memproses file input dengan ribuan baris dan tiba-tiba ada NullPointerException. Anda melihat tempat itu dan menyadari beberapa input salah ... input apa? Anda akan memerlukan informasi lebih lanjut tentang nomor baris, mungkin kolom atau bahkan seluruh teks baris untuk memahami baris apa dalam file yang perlu diperbaiki.