วิธีการจับและวิเคราะห์ข้อผิดพลาด JavaScript
วิศวกรส่วนหน้าทุกคนรู้ว่า JavaScript มีความสามารถในการจัดการข้อยกเว้นพื้นฐาน เราสามารถโยนข้อผิดพลาดใหม่ () และเบราว์เซอร์จะโยนข้อยกเว้นเมื่อเราเรียกข้อผิดพลาด API แต่คาดว่าวิศวกรส่วนหน้าส่วนใหญ่ไม่ได้พิจารณารวบรวมข้อมูลพิเศษเหล่านี้ อย่างไรก็ตามตราบใดที่การรีเฟรชไม่สามารถทำซ้ำได้หลังจากเกิดข้อผิดพลาด JavaScript ผู้ใช้สามารถแก้ปัญหาได้ด้วยการรีเฟรชและเบราว์เซอร์จะไม่พังและมันจะดีถ้ามันไม่ได้เกิดขึ้น สมมติฐานนี้เป็นจริงก่อนที่แอปหน้าเดียวจะได้รับความนิยม แอพหน้าเดียวในปัจจุบันมีความซับซ้อนอย่างมากหลังจากทำงานเป็นระยะเวลาหนึ่ง คุณจะไม่ทำงานใหม่ในการดำเนินการก่อนหน้านี้หรือไม่? ดังนั้นจึงยังจำเป็นที่เราจะต้องจับและวิเคราะห์ข้อมูลข้อยกเว้นเหล่านี้จากนั้นเราสามารถแก้ไขรหัสเพื่อหลีกเลี่ยงการส่งผลกระทบต่อประสบการณ์ผู้ใช้
วิธีจับข้อยกเว้น
เราเขียนข้อผิดพลาดใหม่ () อย่างไรก็ตามข้อยกเว้นที่เกิดขึ้นเมื่อเรียกเบราว์เซอร์ API ไม่จำเป็นต้องจับได้ง่าย สำหรับอดีตเรายังสามารถจับมันได้ผ่านการลองชิวสำหรับหลังเราต้องฟังข้อยกเว้นระดับโลกแล้วจับมัน
ลองจับ
หาก API ของเบราว์เซอร์บางตัวเป็นที่รู้จักกันในการโยนข้อยกเว้นเราจำเป็นต้องนำการโทรเข้าสู่การจับเพื่อหลีกเลี่ยงโปรแกรมทั้งหมดที่เข้าสู่สถานะที่ผิดกฎหมายเนื่องจากข้อผิดพลาด ตัวอย่างเช่น Window.localstorage เป็น API
การคัดลอกรหัสมีดังนี้:
พยายาม {
localstorage.setItem ('วันที่', date.now ());
} catch (ข้อผิดพลาด) {
Reporterror (ข้อผิดพลาด);
-
สถานการณ์ที่ใช้งานได้ทั่วไปอีกประการหนึ่งคือการโทรกลับ เนื่องจากรหัสของฟังก์ชั่นการโทรกลับไม่สามารถควบคุมได้เราจึงไม่ทราบว่ารหัสนั้นดีแค่ไหนและ API อื่น ๆ ที่มีข้อยกเว้นจะถูกเรียกหรือไม่ เพื่อไม่ให้เรียกใช้รหัสอื่น ๆ หลังจากโทรกลับเนื่องจากข้อผิดพลาดในการโทรกลับจำเป็นต้องนำการโทรกลับเข้าสู่การจับ
การคัดลอกรหัสมีดังนี้:
Listeners.foreach (ฟังก์ชั่น (ฟัง) {
พยายาม {
ผู้ฟัง ();
} catch (ข้อผิดพลาด) {
Reporterror (ข้อผิดพลาด);
-
-
window.onerror
สำหรับสถานที่ที่ลองจับไม่สามารถครอบคลุมได้หากมีข้อยกเว้นเกิดขึ้นจะสามารถจับได้ผ่าน Window.onerror เท่านั้น
การคัดลอกรหัสมีดังนี้:
window.onerror =
ฟังก์ชั่น (errorMessage, scripturi, ผ้าลินิน) {
Reporterror ({
ข้อความ: errormessage,
สคริปต์: Scripturi,
บรรทัด: ผ้าลินิน
-
-
ระวังอย่าให้ฉลาดและใช้ window.addeventListener หรือ window.attachevent เพื่อฟัง window.onerror เบราว์เซอร์จำนวนมากใช้ Window.onerror หรือ Window.onerror เท่านั้นการใช้งานเป็นมาตรฐาน เมื่อพิจารณาว่าร่างมาตรฐานยังกำหนด window.onerror เราแค่ต้องใช้ window.onerror
ทรัพย์สินที่ขาดหายไป
สมมติว่าเรามีฟังก์ชั่น Reporterror เพื่อรวบรวมข้อยกเว้นที่จับได้จากนั้นส่งพวกเขาเป็นแบทช์ไปยังที่เก็บข้อมูลฝั่งเซิร์ฟเวอร์สำหรับการสืบค้นและการวิเคราะห์เราต้องการรวบรวมข้อมูลอะไร ข้อมูลที่มีประโยชน์เพิ่มเติมรวมถึง: ประเภทข้อผิดพลาด (ชื่อ) ข้อความแสดงข้อผิดพลาด (ข้อความ) ที่อยู่ไฟล์สคริปต์ (สคริปต์) หมายเลขบรรทัด (บรรทัด) หมายเลขคอลัมน์ (คอลัมน์) และสแต็กติดตาม หากข้อยกเว้นถูกจับได้ผ่านการลองจับข้อมูลทั้งหมดเหล่านี้อยู่ในวัตถุข้อผิดพลาด (สนับสนุนโดยเบราว์เซอร์กระแสหลัก) ดังนั้น Reporterror ยังสามารถรวบรวมข้อมูลนี้ได้ แต่ถ้ามันถูกจับผ่าน Window.onerror เราทุกคนรู้ว่าฟังก์ชั่นเหตุการณ์นี้มีพารามิเตอร์เพียง 3 พารามิเตอร์ดังนั้นข้อมูลอื่นนอกเหนือจากพารามิเตอร์ 3 ตัวเหล่านี้จะหายไป
ทำให้ข้อความเป็นอนุกรม
หากวัตถุข้อผิดพลาดถูกสร้างขึ้นด้วยตัวเราเองข้อผิดพลาดข้อความจะถูกควบคุมโดยเรา โดยพื้นฐานแล้วสิ่งที่เราใส่ลงไปในข้อผิดพลาดข้อความและสิ่งที่จะเป็นพารามิเตอร์แรก (ข้อความ) ของ window.onerror (เบราว์เซอร์ทำการปรับเปลี่ยนเล็กน้อยเช่นการเพิ่ม 'ข้อผิดพลาดที่ไม่ถูกต้อง:' คำนำหน้า) ดังนั้นเราจึงสามารถทำให้แอตทริบิวต์ที่เรากังวลเกี่ยวกับ (เช่น json.stringify) และเก็บไว้ในข้อผิดพลาด พวกเขาอยู่ใน window.onerror เพียงแค่นำมันออกมาและ deserialize มัน แน่นอนว่าสิ่งนี้ จำกัด เฉพาะวัตถุข้อผิดพลาดที่เราสร้างขึ้นเอง
พารามิเตอร์ที่ห้า
ผู้ผลิตเบราว์เซอร์ยังทราบถึงข้อ จำกัด ที่ผู้คนต้องใช้เมื่อใช้ Window.onerror ดังนั้นพวกเขาจึงเริ่มเพิ่มพารามิเตอร์ใหม่ลงใน Window.onerror เมื่อพิจารณาว่ามีเพียงหมายเลขแถวและหมายเลขคอลัมน์ที่ดูเหมือนจะสมมาตรมากเช่นเพิ่มหมายเลขคอลัมน์ก่อนและวางไว้ในพารามิเตอร์ที่สี่ อย่างไรก็ตามสิ่งที่ทุกคนมีความกังวลมากขึ้นคือว่าพวกเขาจะได้รับสแต็คที่สมบูรณ์หรือไม่ดังนั้น Firefox จึงบอกว่ามันจะดีกว่าที่จะวางสแต็กในพารามิเตอร์ที่ห้า แต่ Chrome กล่าวว่ามันจะดีกว่าที่จะใส่วัตถุข้อผิดพลาดทั้งหมดในพารามิเตอร์ที่ห้า เป็นผลให้โครเมี่ยมเร็วขึ้นหน้าต่างใหม่ลายเซ็นที่มีความผิดพลาดถูกนำไปใช้ใน Chrome 30 ส่งผลให้การเขียนร่างมาตรฐานดังต่อไปนี้
การคัดลอกรหัสมีดังนี้:
window.onerror = ฟังก์ชั่น (
errormessage,
Scripturi
ผ้าลินิน
คอลัมน์
ข้อผิดพลาด
-
ถ้า (ข้อผิดพลาด) {
Reporterror (ข้อผิดพลาด);
} อื่น {
Reporterror ({
ข้อความ: errormessage,
สคริปต์: Scripturi,
บรรทัด: ผ้าลินิน
คอลัมน์: คอลัมน์
-
-
-
ความสม่ำเสมอของคุณลักษณะ
ชื่อของคุณสมบัติของวัตถุข้อผิดพลาดที่เราพูดถึงก่อนหน้านี้ขึ้นอยู่กับวิธีการตั้งชื่อ Chrome ดังนั้นเราจึงต้องใช้ฟังก์ชั่นพิเศษเพื่อทำให้วัตถุข้อผิดพลาดเป็นปกตินั่นคือเพื่อแมปชื่อแอตทริบิวต์ที่แตกต่างกับชื่อแอตทริบิวต์แบบครบวงจร สำหรับการปฏิบัติเฉพาะโปรดดูบทความนี้ แม้ว่าการใช้เบราว์เซอร์จะได้รับการอัปเดต แต่ก็ไม่ยากเกินไปสำหรับทุกคนที่จะรักษาตารางการทำแผนที่
ที่คล้ายกันคือรูปแบบการติดตามสแต็ก คุณสมบัตินี้บันทึกข้อมูลสแต็กของข้อยกเว้นเมื่อมันเกิดขึ้นในรูปแบบของข้อความธรรมดา . ชื่อ (ตัวระบุ), ไฟล์ (สคริปต์), บรรทัด (บรรทัด) และคอลัมน์ (คอลัมน์)
ข้อ จำกัด ด้านความปลอดภัย
หากคุณพบข้อผิดพลาดกับข้อความ 'ข้อผิดพลาดสคริปต์' คุณจะเข้าใจสิ่งที่ฉันกำลังพูดถึงซึ่งจริง ๆ แล้วเป็นข้อ จำกัด ของเบราว์เซอร์สำหรับไฟล์สคริปต์จากแหล่งต่าง ๆ เหตุผลสำหรับข้อ จำกัด ด้านความปลอดภัยนี้มีดังนี้: สมมติว่า HTML ที่ส่งคืนโดยนายธนาคารออนไลน์หลังจากการเข้าสู่ระบบนั้นแตกต่างจาก HTML ที่ผู้ใช้ที่ไม่ระบุชื่อเห็นเว็บไซต์บุคคลที่สามสามารถนำ URI ของธนาคารออนไลน์นี้ลงในสคริปต์ แอตทริบิวต์ SRC แน่นอนว่า HTML ไม่สามารถแยกวิเคราะห์เป็น JS ได้ดังนั้นเบราว์เซอร์จะทำการยกเว้นและเว็บไซต์ของบุคคลที่สามนี้สามารถตรวจสอบได้ว่าผู้ใช้เข้าสู่ระบบโดยวิเคราะห์ตำแหน่งของข้อยกเว้นหรือไม่ ด้วยเหตุผลนี้เบราว์เซอร์จะกรองข้อยกเว้นทั้งหมดที่ถูกส่งโดยไฟล์สคริปต์ต้นทางที่แตกต่างกันโดยเหลือเพียงข้อความที่ไม่เปลี่ยนแปลงเช่น 'ข้อผิดพลาดของสคริปต์' และแอตทริบิวต์อื่น ๆ ทั้งหมดจะหายไป
สำหรับเว็บไซต์ในระดับหนึ่งมันเป็นเรื่องปกติสำหรับไฟล์สคริปต์ที่จะวางไว้บน CDN และแหล่งที่มาที่แตกต่างกัน ตอนนี้แม้ว่าคุณจะสร้างเว็บไซต์ขนาดเล็กด้วยตัวคุณเองเฟรมเวิร์กทั่วไปเช่น jQuery และ Backbone สามารถอ้างอิงเวอร์ชันบน CDN สาธารณะโดยตรงเพื่อเพิ่มความเร็วในการดาวน์โหลดผู้ใช้ ดังนั้นข้อ จำกัด ด้านความปลอดภัยนี้ทำให้เกิดปัญหาบางอย่างทำให้ข้อมูลข้อยกเว้นที่เรารวบรวมจาก Chrome และ Firefox เป็น 'ข้อผิดพลาดสคริปต์' ที่ไร้ประโยชน์
ไม้กางเขน
หากคุณต้องการหลีกเลี่ยงข้อ จำกัด นี้เพียงตรวจสอบให้แน่ใจว่าไฟล์สคริปต์และหน้านั้นเหมือนกัน แต่จะไม่วางไฟล์สคริปต์บนเซิร์ฟเวอร์ที่ไม่เร่งความเร็วโดย CDN ลดความเร็วในการดาวน์โหลดของผู้ใช้หรือไม่? ทางออกหนึ่งคือการวางไฟล์สคริปต์ต่อไปบน CDN ให้ใช้ XMLHTTPREQUEST เพื่อดาวน์โหลดเนื้อหากลับผ่าน CORS จากนั้นสร้างแท็ก <Script> เพื่อฉีดเข้าไปในหน้า รหัสที่ฝังอยู่ในหน้านั้นเป็นแหล่งกำเนิดเดียวกัน
นี่เป็นเรื่องง่ายที่จะพูด แต่มีรายละเอียดมากมายที่จะนำไปใช้ เพื่อให้ตัวอย่างง่ายๆ:
การคัดลอกรหัสมีดังนี้:
<script src = "http://cdn.com/step1.js"> </script>
<script>
(ฟังก์ชั่น step2 () {}) ();
</script>
<script src = "http://cdn.com/step3.js"> </script>
เราทุกคนรู้ว่าหากมีการพึ่งพาในขั้นตอนที่ 1, ขั้นตอนที่ 2 และขั้นตอนที่ 3 จะต้องดำเนินการอย่างเคร่งครัดในลำดับนี้มิฉะนั้นอาจเกิดข้อผิดพลาด เบราว์เซอร์สามารถขอไฟล์ STEP1 และ STEP3 ในแบบขนาน แต่รับประกันคำสั่งซื้อเมื่อดำเนินการ หากเราได้รับเนื้อหาไฟล์ของขั้นตอนที่ 1 และขั้นตอนที่ 3 โดยใช้ XMLHTTPREQUEST เราจำเป็นต้องตรวจสอบให้แน่ใจว่าได้รับคำสั่งที่ถูกต้องด้วยตัวเอง นอกจากนี้อย่าลืมขั้นตอนที่ 2
หากเรามีชุดเครื่องมือที่สมบูรณ์เพื่อสร้างแท็ก <Script> สำหรับหน้าต่างๆบนเว็บไซต์เราจำเป็นต้องปรับชุดเครื่องมือนี้เพื่อทำการเปลี่ยนแปลงแท็ก <Script>:
การคัดลอกรหัสมีดังนี้:
<script>
SchedulerEmotescript ('http://cdn.com/step1.js');
</script>
<script>
ScheduceInlInescript (รหัสฟังก์ชัน () {
(ฟังก์ชั่น step2 () {}) ();
-
</script>
<script>
SchedulerEmotescript ('http://cdn.com/step3.js');
</script>
เราจำเป็นต้องใช้ฟังก์ชั่นทั้งสองฟังก์ชั่น SchedulerEmotescript และ ScheduleInLinescript และตรวจสอบให้แน่ใจว่าพวกเขาถูกกำหนดไว้ก่อนแท็ก <Script> แรกที่อ้างอิงไฟล์สคริปต์ภายนอกจากนั้นแท็ก <Script> ที่เหลือจะถูกเขียนลงในรูปแบบข้างต้น โปรดทราบว่าฟังก์ชั่น STEP2 ที่ถูกดำเนินการทันทีถูกวางไว้ในฟังก์ชันรหัสที่ใหญ่กว่า ฟังก์ชั่นรหัสจะไม่ถูกเรียกใช้งานมันเป็นเพียงคอนเทนเนอร์เพื่อให้สามารถเก็บรหัส step2 ดั้งเดิมได้โดยไม่ต้องหลบหนี แต่จะไม่ถูกดำเนินการทันที
ต่อไปเราจำเป็นต้องใช้กลไกที่สมบูรณ์เพื่อให้แน่ใจว่าเนื้อหาไฟล์ที่ดาวน์โหลดโดย SchedulerEmotescript ตามที่อยู่และรหัสที่ได้รับโดยตรงจาก ScheduleInLinescript สามารถดำเนินการทีละหนึ่งในลำดับที่ถูกต้อง ฉันจะไม่ให้รหัสรายละเอียดที่นี่
ตรวจสอบหมายเลขบรรทัด
การรับเนื้อหาผ่าน CORS และการฉีดรหัสลงในหน้าสามารถผ่านข้อ จำกัด ด้านความปลอดภัยได้ แต่มันจะแนะนำปัญหาใหม่นั่นคือความขัดแย้งหมายเลขบรรทัด ในขั้นต้นไฟล์สคริปต์ที่ไม่ซ้ำกันสามารถอยู่ผ่านข้อผิดพลาดได้ข้อความจากนั้นหมายเลขบรรทัดที่ไม่ซ้ำกันสามารถอยู่ได้ผ่านข้อผิดพลาด LINE ตอนนี้เนื่องจากรหัสทั้งหมดที่ฝังอยู่ในหน้าแท็ก <script> หลายแท็กไม่สามารถแยกแยะได้โดยข้อผิดพลาด . ตำแหน่งซอร์สโค้ดที่มีข้อมูลข้อยกเว้น
เพื่อหลีกเลี่ยงความขัดแย้งหมายเลขบรรทัดเราสามารถเสียหมายเลขบรรทัดบางอย่างเพื่อให้ช่วงเวลาหมายเลขบรรทัดที่ใช้โดยรหัสจริงในแต่ละแท็ก <Script> ไม่ทับซ้อนกัน ตัวอย่างเช่นสมมติว่ารหัสจริงในแต่ละแท็ก <Script> แต่ละแท็กไม่เกิน 1,000 บรรทัดฉันสามารถสร้างรหัสในแท็ก <Script> ครั้งแรก Take Up Line 11000 และแท็ก <Script> ที่สองแท็กรหัสในรหัสครอบครองบรรทัด 10012000 (1,000 สายว่างเปล่าถูกแทรกก่อนที่จะแทรก) รหัสของแท็ก <Script> ที่สามใช้บรรทัด 20013000 (เส้นเปล่า 2,000 สายถูกแทรกก่อนที่จะแทรก) และอื่น ๆ จากนั้นเราใช้แอตทริบิวต์ Data-* เพื่อบันทึกข้อมูลนี้เพื่อการตรวจสอบย้อนกลับได้ง่าย
การคัดลอกรหัสมีดังนี้:
<สคริปต์
data-src = "http://cdn.com/step1.js"
Data-line-start = "1"
-
// รหัสสำหรับขั้นตอนที่ 1
</script>
<สคริปต์ data-line-start = "1001">
// '/n' * 1000
// รหัสสำหรับขั้นตอนที่ 2
</script>
<สคริปต์
data-src = "http://cdn.com/step3.js"
Data-line-start = "2001"
-
// '/n' * 2000
// รหัสสำหรับขั้นตอนที่ 3
</script>
หลังจากการประมวลผลนี้หากเกิดข้อผิดพลาดข้อผิดพลาดคือ 3005 หมายความว่าข้อผิดพลาดจริงควรเป็น 'http://cdn.com/step3.js' ในขณะที่ข้อผิดพลาดจริงควรเป็น 5 เราสามารถกรอกหมายเลขบรรทัดนี้ย้อนกลับตรวจสอบในฟังก์ชั่น Reporterror ที่กล่าวถึงก่อนหน้านี้
แน่นอนเนื่องจากเราไม่สามารถรับประกันได้ว่าแต่ละไฟล์สคริปต์มีเพียง 1,000 บรรทัดจึงเป็นไปได้ว่าไฟล์สคริปต์บางไฟล์มีน้อยกว่า 1,000 บรรทัดอย่างมีนัยสำคัญดังนั้นจึงไม่จำเป็นต้องจัดสรรช่วงเวลา 1,000 บรรทัดให้กับแท็ก <Script> แต่ละแท็ก เราสามารถจัดสรรช่วงเวลาตามจำนวนสคริปต์ที่แท้จริงเพียงตรวจสอบให้แน่ใจว่าช่วงเวลาที่ใช้โดยแต่ละแท็ก <Script> ไม่ทับซ้อนกัน
แอตทริบิวต์ Crossorigin
ข้อ จำกัด ด้านความปลอดภัยที่กำหนดโดยเบราว์เซอร์เกี่ยวกับเนื้อหาจากแหล่งต่าง ๆ นั้นไม่ได้ จำกัด อยู่ที่แท็ก <Script> เนื่องจาก XMLHTTPREQUEST สามารถฝ่าฟันข้อ จำกัด นี้ผ่าน CORS ทำไมทรัพยากรจึงถูกอ้างอิงโดยตรงผ่านแท็กที่ไม่ได้รับอนุญาต? แน่นอนว่าโอเค
ข้อ จำกัด ของการอ้างอิงไปยังไฟล์สคริปต์ต้นทางที่แตกต่างกันสำหรับแท็ก <Script> ยังใช้กับการอ้างอิงถึงไฟล์ภาพต้นฉบับที่แตกต่างกันสำหรับแท็ก <IMG> หากแท็ก <img> เป็นแหล่งที่แตกต่างกันเมื่อใช้ในการวาด <sanvas>, <sanvas> จะกลายเป็นสถานะการเขียนเท่านั้นเพื่อให้แน่ใจว่าเว็บไซต์ไม่สามารถขโมยข้อมูลภาพที่ไม่ได้รับอนุญาตจากแหล่งต่าง ๆ ผ่าน JavaScript ต่อมาแท็ก <IMG> แก้ไขปัญหานี้โดยการแนะนำแอตทริบิวต์ crossorigin ถ้า crossorigin = "ไม่ระบุชื่อ" มันจะเทียบเท่ากับ cors ที่ไม่ระบุชื่อ;
เนื่องจากแท็ก <IMG> สามารถทำสิ่งนี้ได้ทำไมแท็ก <Script> ถึงทำสิ่งนี้ไม่ได้? ดังนั้นผู้ผลิตเบราว์เซอร์จึงเพิ่มแอตทริบิวต์ crossorigin เดียวกันลงในแท็ก <script> เพื่อแก้ข้อ จำกัด ด้านความปลอดภัยด้านบน ตอนนี้การสนับสนุน Chrome และ Firefox สำหรับสถานที่ให้บริการนี้ฟรีอย่างสมบูรณ์ Safari จะรักษา crossorigin = "anonymous" เป็น crossorigin = "use-credentials" และผลที่ได้คือถ้าเซิร์ฟเวอร์รองรับ Cors ที่ไม่ระบุชื่อเท่านั้น SAFARI จะถือว่าการรับรองความถูกต้องเป็นความล้มเหลว เนื่องจากเซิร์ฟเวอร์ CDN ได้รับการออกแบบมาเพื่อส่งคืนเนื้อหาแบบคงที่ด้วยเหตุผลด้านประสิทธิภาพจึงเป็นไปไม่ได้ที่จะส่งคืนส่วนหัว HTTP ที่จำเป็นในการตรวจสอบความถูกต้องของ CORS ตามคำขอ
สรุป
การจัดการข้อยกเว้นของ JavaScript ดูง่ายและไม่แตกต่างจากภาษาอื่น ๆ แต่ไม่ใช่เรื่องง่ายที่จะจับข้อยกเว้นทั้งหมดและวิเคราะห์คุณสมบัติ แม้ว่าบริการของบุคคลที่สามบางแห่งจะให้บริการ Google Analytics ที่จับข้อยกเว้น JavaScript หากคุณต้องการเข้าใจรายละเอียดและหลักการคุณต้องทำด้วยตัวเอง