Nama yang lebih baik untuk NaN
, menggambarkan maknanya lebih tepat dan kurang membingungkan, akan menjadi pengecualian numerik . Ini benar-benar jenis pengecualian objek lain yang menyamar sebagai memiliki tipe primitif (oleh desain bahasa), di mana pada saat yang sama ia tidak diperlakukan sebagai primitif dalam perbandingan diri yang salah. Dari mana kebingungan. Dan selama bahasa "tidak akan mengambil keputusan" untuk memilih antara objek pengecualian yang tepat dan bilangan primitif , kebingungan akan tetap ada.
Ketidaksamaan yang terkenal NaN
itu sendiri, keduanya ==
dan ===
merupakan manifestasi dari desain yang membingungkan memaksa objek pengecualian ini menjadi tipe primitif. Ini mematahkan prinsip fundamental bahwa primitif secara unik ditentukan oleh nilainya . Jika NaN
lebih disukai dilihat sebagai perkecualian (yang bisa ada jenisnya berbeda), maka itu tidak boleh "dijual" sebagai primitif. Dan jika ingin menjadi primitif, prinsip itu harus dipegang. Selama itu rusak, seperti yang kita miliki dalam JavaScript, dan kita tidak bisa benar-benar memutuskan di antara keduanya, kebingungan yang mengarah pada beban kognitif yang tidak perlu bagi semua orang yang terlibat akan tetap ada. Namun, yang sangat mudah diperbaiki dengan hanya membuat pilihan di antara keduanya:
- baik membuat
NaN
objek pengecualian khusus yang berisi informasi berguna tentang bagaimana pengecualian muncul, sebagai lawan membuang informasi itu seperti apa yang saat ini diterapkan, yang mengarah ke kode yang lebih sulit untuk debug;
- atau membuat
NaN
suatu entitas dari tipe primitif number
(yang bisa kurang membingungkan disebut "numerik"), dalam hal ini harus sama dengan dirinya sendiri dan tidak dapat berisi informasi lain; yang terakhir jelas merupakan pilihan yang lebih rendah.
Satu-satunya keuntungan dari memaksakan NaN
ke dalam number
tipe adalah dapat membuangnya kembali ke ekspresi numerik apa pun. Namun, yang membuatnya menjadi pilihan yang rapuh, karena hasil dari setiap ekspresi numerik yang mengandung NaN
akan menjadi NaN
, atau mengarah ke hasil yang tidak dapat diprediksi seperti NaN < 0
mengevaluasi false
, yaitu mengembalikanboolean
alih-alih menjaga pengecualian.
Dan bahkan jika "segala sesuatunya seperti itu", tidak ada yang menghalangi kita untuk membuat perbedaan yang jelas untuk diri kita sendiri, untuk membantu membuat kode kita lebih mudah diprediksi dan lebih mudah disangkal. Dalam praktiknya, itu berarti mengidentifikasi pengecualian-pengecualian itu dan menanganinya sebagai pengecualian. Yang, sayangnya, berarti lebih banyak kode tetapi mudah-mudahan akan dikurangi dengan alat seperti TypeScript dari Flowtype.
Dan kemudian kita memiliki berantakan tenang vs berisik alias sinyal NaN
perbedaan . Yang benar-benar adalah tentang bagaimana pengecualian ditangani, bukan pengecualian itu sendiri, dan tidak ada yang berbeda dari pengecualian lainnya.
Demikian pula, Infinity
dan +Infinity
elemen-elemen tipe numerik yang muncul dalam ekstensi garis nyata tetapi mereka bukan bilangan real. Secara matematis, mereka dapat diwakili oleh urutan bilangan real yang konvergen ke salah satu +
atau -Infinity
.