Pengecualian JavaScript mengendalikan kemahiran explanation_javascript terperinci

Jurutera hadapan semua tahu bahawa JavaScript mempunyai keupayaan pengendalian pengecualian asas. Kami boleh membuang Ralat baharu(), dan penyemak imbas juga akan membuang pengecualian apabila kami membuat ralat semasa memanggil API. Tetapi dianggarkan kebanyakan jurutera hadapan tidak pernah mempertimbangkan untuk mengumpul maklumat yang tidak normal ini

Bagaimanapun, selagi ralat JavaScript tidak muncul semula selepas menyegarkan, pengguna boleh menyelesaikan masalah dengan menyegarkan dan penyemak imbas tidak akan ranap. Andaian ini berlaku sebelum Apl Halaman Tunggal menjadi popular. Status Apl Halaman Tunggal semasa menjadi sangat rumit selepas dijalankan untuk tempoh masa Pengguna mungkin telah melakukan beberapa operasi input sebelum tiba di sini. Bukankah operasi sebelumnya sepatutnya dibuat semula sepenuhnya? Oleh itu, kami masih perlu menangkap dan menganalisis maklumat pengecualian ini, dan kemudian kami boleh mengubah suai kod untuk mengelak daripada menjejaskan pengalaman pengguna.

Cara menangkap pengecualian

Ralat baru lontaran() yang kami tulis sendiri pastinya boleh ditangkap jika kami mahu, kerana kami tahu dengan tepat di mana lontaran ditulis. Walau bagaimanapun, pengecualian yang berlaku apabila memanggil API penyemak imbas tidak semestinya mudah ditangkap Sesetengah API ditulis dalam piawaian untuk membuang pengecualian, dan sesetengah API hanya dilemparkan oleh penyemak imbas individu disebabkan oleh perbezaan pelaksanaan atau kecacatan. Untuk yang pertama, kita juga boleh menangkapnya melalui cuba-tangkap Untuk yang terakhir, kita mesti mendengar pengecualian global dan kemudian menangkapnya.

cuba tangkap

Jika sesetengah API penyemak imbas diketahui membuang pengecualian, maka kita perlu meletakkan panggilan dalam try-catch untuk menghalang keseluruhan program daripada memasuki keadaan haram akibat ralat. Sebagai contoh, window.localStorage ialah API sedemikian. Ia akan mengeluarkan pengecualian selepas menulis data melebihi had kapasiti Ini juga akan berlaku dalam mod penyemakan imbas peribadi.

Salin kod Kod adalah seperti berikut:

cuba {
localStorage.setItem('date', Date.now());
} tangkap (ralat) {
reportError(error);
}

Satu lagi kes penggunaan biasa untuk try-catch ialah panggilan balik. Oleh kerana kod fungsi panggil balik di luar kawalan kami, kami tidak tahu tentang kualiti kod atau sama ada API lain yang akan mengeluarkan pengecualian akan dipanggil. Untuk mengelakkan kod lain selepas memanggil balik daripada tidak dapat dilaksanakan kerana ralat panggil balik, panggilan balik perlu dimasukkan ke dalam try-catch.

Salin kod Kod adalah seperti berikut:

listeners.forEach(function(pendengar) {
cuba {
pendengar();
} tangkap (ralat) {
reportError(error);
}
});

tetingkap.onerror

Untuk kawasan yang tidak diliputi oleh try-catch, jika pengecualian berlaku, ia hanya boleh ditangkap melalui window.onerror.

Salin kod Kod adalah seperti berikut:

window.onerror =
function(errorMessage, scriptURI, lineNumber) {
reportError({
mesej: errorMessage,
skrip: scriptURI,
baris: lineNumber
});
}

Berhati-hati untuk tidak menjadi pandai dan gunakan window.addEventListener atau window.attachEvent untuk mendengar window.onerror. Banyak pelayar hanya melaksanakan window.onerror, atau hanya pelaksanaan window.onerror adalah standard. Memandangkan draf standard juga mentakrifkan window.onerror, kita hanya boleh menggunakan window.onerror.

Atribut hilang

Andaikan kami mempunyai fungsi reportError untuk mengumpul pengecualian yang ditangkap, dan kemudian menghantarnya ke storan sisi pelayan secara berkelompok untuk pertanyaan dan analisis, maka apakah maklumat yang ingin kami kumpulkan? Maklumat yang lebih berguna termasuk: jenis ralat (nama), mesej ralat (mesej), alamat fail skrip (skrip), nombor baris (baris), nombor lajur (lajur) dan surih tindanan (tindanan). Jika pengecualian ditangkap melalui cuba-tangkap, maklumat ini berada pada objek Ralat (disokong oleh penyemak imbas arus perdana), jadi reportError juga boleh mengumpul maklumat ini. Tetapi jika ia ditangkap melalui window.onerror, kita semua tahu bahawa fungsi acara ini hanya mempunyai 3 parameter, jadi maklumat yang tidak dijangka dari 3 parameter ini hilang.

Mesej bersiri

Jika objek Ralat dicipta oleh kami sendiri, maka error.message dikawal oleh kami. Pada asasnya, apa sahaja yang kita masukkan ke dalam error.message, parameter pertama (message) window.onerror ialah. (Penyemak imbas sebenarnya akan membuat sedikit pengubahsuaian, seperti menambah awalan 'Ralat Tidak Ditangkap:'.) Oleh itu, kita boleh mensirikan sifat yang kita sayangi (seperti JSON.Stringify) dan menyimpannya dalam error.message, dan kemudian membacanya dalam window.onerror Hanya keluarkan dan nyahserikannya. Sudah tentu, ini terhad kepada objek Ralat yang kita cipta sendiri.

Parameter kelima

Pengilang penyemak imbas juga mengetahui batasan yang dihadapi oleh orang ramai apabila menggunakan window.onerror, jadi mereka mula menambah parameter baharu pada window.onerror. Memandangkan hanya nombor baris tetapi tiada nombor lajur kelihatan tidak terlalu simetri, IE mula-mula menambah nombor lajur dan meletakkannya dalam parameter keempat. Walau bagaimanapun, semua orang lebih mengambil berat tentang sama ada mereka boleh mendapatkan tindanan lengkap, jadi Firefox berkata adalah lebih baik untuk meletakkan tindanan dalam parameter kelima. Tetapi Chrome berkata bahawa adalah lebih baik untuk meletakkan keseluruhan objek Ralat dalam parameter kelima Anda boleh membaca mana-mana sifat yang anda inginkan, termasuk sifat tersuai. Akibatnya, Chrome bergerak lebih pantas dan melaksanakan tetingkap baharu. tandatangan onerror dalam Chrome 30, yang menyebabkan draf standard ditulis dengan sewajarnya.

Salin kod Kod adalah seperti berikut:

window.onerror = function(
mesej ralat,
scriptURI,
Nombor baris,
Nombor lajur,
ralat
) {
jika (ralat) {
reportError(error);
} lain {
reportError({
mesej: errorMessage,
skrip: scriptURI,
baris: lineNumber，
lajur: lajurNombor
});
}
}

Penyaturan atribut

Nama atribut objek Ralat yang kami bincangkan sebelum ini adalah berdasarkan kaedah penamaan Chrome Walau bagaimanapun, penyemak imbas yang berbeza menamakan atribut objek Ralat secara berbeza Contohnya, alamat fail skrip dipanggil skrip dalam Chrome tetapi dipanggil nama fail dalam Firefox. . Oleh itu, kita juga memerlukan fungsi khas untuk menormalkan objek Ralat, iaitu, untuk memetakan nama atribut yang berbeza kepada nama atribut bersatu. Untuk kaedah khusus, sila rujuk artikel ini. Walaupun pelaksanaan penyemak imbas akan dikemas kini, mengekalkan jadual pemetaan sedemikian secara manual tidaklah terlalu sukar.

Serupa dengan format surih tindanan. Atribut ini menyimpan timbunan maklumat pengecualian dalam bentuk teks biasa Memandangkan format teks yang digunakan oleh setiap penyemak imbas adalah berbeza, ia juga perlu mengekalkan ungkapan biasa secara manual untuk mengekstrak fungsi setiap bingkai daripada teks biasa (. pengecam), fail (skrip), nombor baris (baris) dan nombor lajur (lajur).

Sekatan keselamatan

Jika anda juga mengalami ralat dengan mesej 'Skrip ralat.', anda akan memahami perkara yang saya maksudkan Ini sebenarnya adalah had penyemak imbas untuk fail skrip dari asal yang berbeza. Sebab untuk sekatan keselamatan ini adalah ini: dengan mengandaikan bahawa HTML yang dikembalikan oleh bank dalam talian selepas pengguna log masuk adalah berbeza daripada HTML yang dilihat oleh pengguna tanpa nama, tapak web pihak ketiga boleh meletakkan URI bank dalam talian ke dalam skrip. atribut src. Sudah tentu, HTML tidak boleh dihuraikan sebagai JS, jadi penyemak imbas akan membuang pengecualian, dan tapak web pihak ketiga boleh menentukan sama ada pengguna dilog masuk dengan menghuraikan lokasi pengecualian. Atas sebab ini, penyemak imbas menapis semua pengecualian yang dilemparkan oleh fail skrip daripada sumber yang berbeza sehingga hanya satu mesej yang tidak berubah seperti 'Ralat skrip yang tinggal, dan semua atribut lain hilang.

Untuk tapak web dalam skala tertentu, adalah perkara biasa untuk fail skrip diletakkan pada CDN dengan sumber yang berbeza. Sekarang walaupun anda membina tapak web kecil anda sendiri, rangka kerja biasa seperti jQuery dan Backbone boleh merujuk terus versi pada CDN awam untuk mempercepatkan muat turun pengguna. Jadi sekatan keselamatan ini menyebabkan beberapa masalah, menyebabkan maklumat pengecualian yang kami kumpulkan daripada Chrome dan Firefox menjadi 'Ralat Skrip' yang sia-sia.

CORS

Untuk memintas sekatan ini, cuma pastikan fail skrip dan halaman itu sendiri mempunyai asal yang sama. Tetapi meletakkan fail skrip pada pelayan yang tidak dipercepatkan oleh CDN tidak akan memperlahankan kelajuan muat turun pengguna? Satu penyelesaian ialah dengan terus meletakkan fail skrip pada CDN, gunakan XMLHttpRequest untuk memuat turun semula kandungan melalui CORS, dan kemudian buat teg Kod yang dibenamkan dalam halaman sudah tentu dari sumber yang sama.

Ini kelihatan mudah, tetapi terdapat banyak butiran untuk dilaksanakan. Mari kita gunakan contoh mudah:

Salin kod Kod adalah seperti berikut:

">http://cdn.com/step1.js">>

(fungsi step2() {})();

">http://cdn.com/step3.js">>

Kita semua tahu bahawa jika terdapat kebergantungan antara step1, step2 dan step3, ia mesti dilaksanakan dengan ketat dalam susunan ini, jika tidak ralat mungkin berlaku. Penyemak imbas boleh meminta fail step1 dan step3 secara selari, tetapi pesanan itu dijamin semasa pelaksanaan. Jika kami memperoleh sendiri kandungan fail step1 dan step3 melalui XMLHttpRequest, kami perlu memastikan ketepatan pesanan itu. Di samping itu, jangan lupa step2. Step2 boleh dilaksanakan apabila step1 dimuat turun secara tidak menyekat, jadi kita juga mesti campur tangan secara manual dalam step2 untuk membiarkannya menunggu langkah1 selesai sebelum melaksanakannya.

Jika kami sudah mempunyai set alat untuk menjana teg untuk halaman yang berbeza di tapak web, kami perlu melaraskan set alat ini untuk membuat perubahan pada teg

Salin kod Kod adalah seperti berikut:

scheduleRemoteScript('http://cdn.com/step1.js');


scheduleInlineScript(kod fungsi() {
(fungsi step2() {})();
});


scheduleRemoteScript('http://cdn.com/step3.js');




Kami perlu melaksanakan dua fungsi scheduleRemoteScript dan scheduleInlineScript, dan memastikan bahawa ia ditakrifkan sebelum teg yang merujuk kepada fail skrip luaran, dan kemudian teg Ambil perhatian bahawa fungsi step2 yang pada asalnya dilaksanakan serta-merta telah diletakkan dalam fungsi kod yang lebih besar. Fungsi kod tidak akan dilaksanakan, ia hanya bekas, supaya kod asal langkah 2 boleh dikekalkan tanpa melarikan diri, tetapi tidak akan dilaksanakan serta-merta.

Seterusnya kita perlu melaksanakan mekanisme lengkap untuk memastikan kandungan fail yang dimuat turun oleh scheduleRemoteScript berdasarkan alamat dan kod yang diperoleh secara langsung oleh scheduleInlineScript boleh dilaksanakan satu demi satu dalam susunan yang betul. Saya tidak akan memberikan kod terperinci di sini Jika anda berminat, anda boleh melaksanakannya sendiri.

Semakan nombor baris terbalik

Mendapatkan kandungan melalui CORS dan kemudian menyuntik kod ke dalam halaman boleh menembusi sekatan keselamatan, tetapi ia akan memperkenalkan masalah baharu, iaitu konflik nombor baris. Pada asalnya, error.script boleh digunakan untuk mencari fail skrip unik dan error.line boleh digunakan untuk mencari nombor baris unik. Sekarang, kerana kesemuanya adalah kod yang dibenamkan dalam halaman, berbilang digunakan untuk mencari lokasi kod sumber di mana ralat berada.

Untuk mengelakkan konflik nombor baris, kita boleh membazirkan beberapa nombor baris supaya julat nombor baris yang digunakan oleh kod sebenar dalam setiap teg Sebagai contoh, dengan mengandaikan bahawa kod sebenar dalam setiap teg tidak lebih daripada 1000 baris, maka saya boleh membiarkan kod dalam teg pertama menduduki baris 1–1000, dan biarkan kod kedua dalam Teg menduduki baris 1001–2000 (didahului dengan 1000 baris kosong), dan kod dalam teg ketiga menduduki baris 2001–3000 (didahului dengan 2000 baris kosong). Kemudian kami menggunakan atribut data-* untuk merekodkan maklumat ini agar mudah diperoleh.

Salin kod Kod adalah seperti berikut:

data-src="http://cdn.com/step1.js"
data-line-start="1"
>
// kod untuk langkah 1

Selepas pemprosesan ini, jika error.line bagi ralat ialah 3005, ini bermakna error.script sebenar hendaklah 'http://cdn.com/step3.js' dan error.line sebenar hendaklah 5 . Kita boleh melengkapkan semakan terbalik nombor baris ini dalam fungsi reportError yang dinyatakan sebelum ini.

Sudah tentu, kerana kami tidak dapat menjamin bahawa setiap fail skrip hanya mempunyai 1000 baris dan sesetengah fail skrip mungkin kurang daripada 1000 baris, anda tidak perlu memperuntukkan julat tetap 1000 baris untuk setiap teg . Kami boleh memperuntukkan selang berdasarkan bilangan sebenar baris skrip, selagi selang yang digunakan oleh setiap teg

atribut silang asal

Sekatan keselamatan yang dikenakan oleh penyemak imbas pada kandungan daripada sumber yang berbeza sudah tentu tidak terhad kepada teg Memandangkan XMLHttpRequest boleh menembusi had ini melalui CORS, mengapa sumber tidak boleh dirujuk terus melalui teg? Sudah tentu ini mungkin.

Sekatan pada teg merujuk fail skrip daripada sumber yang berbeza juga dikenakan pada teg Jika teg adalah daripada sumber yang berbeza, sebaik sahaja ia digunakan dalam lukisan Kemudian teg menyelesaikan masalah ini dengan memperkenalkan atribut silang asal. Jika anda menggunakan crossorigin="anonymous", ia bersamaan dengan CORS tanpa nama jika anda menggunakan `crossorigin="use-credentials", ia bersamaan dengan CORS dengan pengesahan.

Jika teg boleh melakukan ini, mengapa teg Jadi pengeluar penyemak imbas menambahkan atribut silang asal yang sama pada teg Chrome dan Firefox kini menyokong atribut ini tanpa sebarang masalah. Safari akan menganggap crossorigin="anonymous" sebagai crossorigin="use-credentials". Akibatnya, jika pelayan hanya menyokong CORS tanpa nama, Safari akan menganggap pengesahan sebagai gagal. Memandangkan pelayan CDN direka untuk hanya mengembalikan kandungan statik atas sebab prestasi, adalah mustahil untuk mengembalikan Pengepala HTTP yang diperlukan secara dinamik untuk pengesahan CORS berdasarkan permintaan Safari tidak boleh menggunakan ciri ini untuk menyelesaikan masalah di atas.

Ringkasan

Pengendalian pengecualian JavaScript kelihatan sangat mudah, tidak berbeza dengan bahasa lain, tetapi sebenarnya tidak semudah itu untuk menangkap semua pengecualian dan kemudian menganalisis atribut. Walaupun terdapat beberapa perkhidmatan pihak ketiga yang menyediakan perkhidmatan seperti Analitis Google yang menangkap pengecualian JavaScript, jika anda ingin memahami butiran dan prinsip, anda masih perlu melakukannya sendiri.