Hướng dẫn rõ ràng để xử lý lỗi trong JavaScript

Định luật Murphy nói rằng bất cứ điều gì có thể sai thì cuối cùng cũng sẽ sai. Điều này áp dụng một chút quá tốt trong thế giới lập trình. Nếu bạn tạo một ứng dụng, rất có thể bạn sẽ tạo ra lỗi và các vấn đề khác. Lỗi trong JavaScript là một trong những vấn đề phổ biến!

Thành công của một sản phẩm phần mềm phụ thuộc vào việc người tạo ra nó có thể giải quyết những vấn đề này tốt như thế nào trước khi làm tổn thương người dùng của họ. Và JavaScript, trong số tất cả các ngôn ngữ lập trình, nổi tiếng với thiết kế xử lý lỗi trung bình của nó.

Nếu bạn đang xây dựng một ứng dụng JavaScript, có nhiều khả năng bạn sẽ làm rối tung các loại dữ liệu vào lúc này hay lúc khác. Nếu không, bạn có thể thay thế một toán tử không xác định bằng một null hoặc một toán tử bằng ba ( === ) bằng một toán tử bằng kép ( == ).

Chỉ có con người mới mắc sai lầm. Đây là lý do tại sao chúng tôi sẽ chỉ cho bạn mọi thứ bạn cần biết về việc xử lý lỗi trong JavaScript.

Bài viết này sẽ hướng dẫn bạn các lỗi cơ bản trong JavaScript và giải thích các lỗi khác nhau mà bạn có thể gặp phải. Sau đó, bạn sẽ học cách xác định và sửa các lỗi này. Ngoài ra còn có một số mẹo để xử lý lỗi hiệu quả trong môi trường sản xuất.

Không cần quảng cáo thêm, chúng ta hãy bắt đầu!

Lỗi JavaScript là gì?

Lỗi trong lập trình đề cập đến các tình huống không cho phép một chương trình hoạt động bình thường. Điều này có thể xảy ra khi một chương trình không biết cách xử lý công việc hiện tại, chẳng hạn như khi cố gắng mở một tệp không tồn tại hoặc tiếp cận với điểm cuối API dựa trên web trong khi không có kết nối mạng.

Những tình huống này đẩy chương trình ném lỗi cho người dùng, nói rằng nó không biết cách tiến hành. Chương trình thu thập càng nhiều thông tin càng tốt về lỗi và sau đó báo cáo rằng nó không thể tiếp tục.

Các nhà lập trình thông minh cố gắng dự đoán và bao quát các tình huống này để người dùng không phải tìm ra thông báo lỗi kỹ thuật như “404” một cách độc lập. Thay vào đó, họ hiển thị một thông báo dễ hiểu hơn nhiều: “Không thể tìm thấy trang.”

Lỗi trong JavaScript là các đối tượng được hiển thị bất cứ khi nào xảy ra lỗi lập trình. Các đối tượng này chứa thông tin phong phú về loại lỗi, câu lệnh gây ra lỗi và dấu vết ngăn xếp khi lỗi xảy ra. JavaScript cũng cho phép các lập trình viên tạo ra các lỗi tùy chỉnh để cung cấp thêm thông tin khi gỡ lỗi các vấn đề.

Thuộc tính của một lỗi

Bây giờ định nghĩa về lỗi JavaScript đã rõ ràng, đã đến lúc đi sâu vào chi tiết.

Lỗi trong JavaScript mang các thuộc tính tiêu chuẩn và tùy chỉnh nhất định giúp hiểu nguyên nhân và ảnh hưởng của lỗi. Theo mặc định, lỗi trong JavaScript chứa ba thuộc tính:

1. thông báo : Một giá trị chuỗi mang thông báo lỗi
2. name : Loại lỗi đã xảy ra (Chúng ta sẽ đi sâu vào vấn đề này trong phần tiếp theo)
3. stack : Dấu vết ngăn xếp của mã được thực thi khi xảy ra lỗi.

Ngoài ra, lỗi cũng có thể mang các thuộc tính như columnNumber, lineNumber, fileName, v.v., để mô tả lỗi tốt hơn. Tuy nhiên, các thuộc tính này không phải là tiêu chuẩn và có thể có hoặc không có trong mọi đối tượng lỗi được tạo từ ứng dụng JavaScript của bạn.

Hiểu về dấu vết ngăn xếp

Dấu vết ngăn xếp là danh sách các lệnh gọi phương thức mà một chương trình đã sử dụng khi một sự kiện như ngoại lệ hoặc cảnh báo xảy ra. Đây là một dấu vết ngăn xếp mẫu kèm theo một ngoại lệ trông giống như sau:

Như bạn có thể thấy, nó bắt đầu bằng cách in tên lỗi và thông báo, sau đó là danh sách các phương thức đã được gọi. Mỗi lệnh gọi phương thức cho biết vị trí của mã nguồn của nó và dòng tại đó nó được gọi. Bạn có thể sử dụng dữ liệu này để điều hướng qua cơ sở mã của mình và xác định đoạn mã nào đang gây ra lỗi.

Danh sách các phương pháp này được sắp xếp theo kiểu xếp chồng lên nhau. Nó cho biết nơi mà ngoại lệ của bạn được đưa ra đầu tiên và cách nó lan truyền thông qua các lệnh gọi phương thức xếp chồng lên nhau. Việc triển khai bắt ngoại lệ sẽ không để nó lan truyền qua ngăn xếp và làm hỏng chương trình của bạn. Tuy nhiên, bạn có thể muốn để lại các lỗi nghiêm trọng không cố ý làm hỏng chương trình trong một số trường hợp.

Lỗi so với Ngoại lệ

Hầu hết mọi người thường coi lỗi và ngoại lệ là cùng một thứ. Tuy nhiên, cần lưu ý một sự khác biệt nhỏ nhưng cơ bản giữa chúng.

Để hiểu rõ hơn điều này, chúng ta hãy lấy một ví dụ nhanh. Đây là cách bạn có thể xác định lỗi trong JavaScript:

const wrongTypeError = TypeError("Wrong type found, expected character")

Và đây là cách đối tượng wrongTypeError trở thành một ngoại lệ:

throw wrongTypeError

Tuy nhiên, hầu hết mọi người có xu hướng sử dụng dạng viết tắt để xác định các đối tượng lỗi trong khi ném chúng:

throw TypeError("Wrong type found, expected character")

Đây là thông lệ tiêu chuẩn. Tuy nhiên, đó là một trong những lý do tại sao các nhà phát triển có xu hướng trộn lẫn các ngoại lệ và lỗi. Do đó, việc nắm rõ các nguyên tắc cơ bản là rất quan trọng ngay cả khi bạn sử dụng các cách viết tắt để hoàn thành công việc một cách nhanh chóng.

Các loại lỗi trong JavaScript

Có một loạt các loại lỗi được xác định trước trong JavaScript. Chúng được thời gian chạy JavaScript tự động chọn và xác định bất cứ khi nào lập trình viên không xử lý rõ ràng các lỗi trong ứng dụng.

Phần này sẽ hướng dẫn bạn một số loại lỗi phổ biến nhất trong JavaScript và hiểu khi nào và tại sao chúng xảy ra.

RangeError

Lỗi RangeError được đưa ra khi một biến được đặt với giá trị nằm ngoài phạm vi giá trị pháp lý của nó. Nó thường xảy ra khi truyền một giá trị làm đối số cho một hàm và giá trị đã cho không nằm trong phạm vi tham số của hàm. Đôi khi có thể khó khắc phục khi sử dụng thư viện bên thứ ba được ghi chép kém vì bạn cần biết phạm vi giá trị có thể có để các đối số chuyển vào giá trị chính xác.

Một số trường hợp phổ biến trong đó RangeError xảy ra là:

• Cố gắng tạo một mảng có độ dài không hợp lệ thông qua phương thức khởi tạo Array.
• Truyền các giá trị không hợp lệ cho các phương thức số như toExponential() , toPrecision() , toFixed() , v.v.
• Truyền các giá trị bất hợp pháp cho các hàm chuỗi như normalize() .

ReferenceError

Một ReferenceError xảy ra khi có điều gì đó không ổn với tham chiếu của một biến trong mã của bạn. Bạn có thể đã quên xác định một giá trị cho biến trước khi sử dụng nó hoặc bạn có thể đang cố gắng sử dụng một biến không thể truy cập được trong mã của mình. Trong mọi trường hợp, đi qua dấu vết ngăn xếp cung cấp nhiều thông tin để tìm và sửa tham chiếu biến bị lỗi.

Một số lý do phổ biến khiến ReferenceErrors xảy ra là:

• Đánh máy một tên biến.
• Cố gắng truy cập các biến phạm vi khối bên ngoài phạm vi của chúng.
• Tham chiếu đến một biến toàn cục từ một thư viện bên ngoài (như $ từ jQuery) trước khi nó được tải.

Lỗi cú pháp

Những lỗi này là một trong những lỗi đơn giản nhất để sửa vì chúng chỉ ra lỗi trong cú pháp của mã. Vì JavaScript là ngôn ngữ kịch bản được thông dịch chứ không phải được biên dịch, những ngôn ngữ này được ném ra khi ứng dụng thực thi tập lệnh có lỗi. Trong trường hợp ngôn ngữ biên dịch, các lỗi như vậy được xác định trong quá trình biên dịch. Do đó, các tệp nhị phân ứng dụng không được tạo cho đến khi chúng được sửa.

Một số lý do phổ biến khiến SyntaxErrors có thể xảy ra là:

• Thiếu dấu phẩy ngược
• Thiếu dấu ngoặc đơn đóng
• Căn chỉnh không đúng các dấu ngoặc nhọn hoặc các ký tự khác

Bạn nên sử dụng một công cụ linting trong IDE của mình để xác định những lỗi như vậy cho bạn trước khi chúng xuất hiện trên trình duyệt.

TypeError

TypeError là một trong những lỗi phổ biến nhất trong các ứng dụng JavaScript. Lỗi này được tạo ra khi một số giá trị không thuộc loại cụ thể được mong đợi. Một số trường hợp phổ biến khi nó xảy ra là:

• Gọi các đối tượng không phải là phương thức.
• Cố gắng truy cập thuộc tính của các đối tượng rỗng hoặc không xác định
• Xử lý một chuỗi là một số hoặc ngược lại

Có nhiều khả năng hơn mà TypeError có thể xảy ra. Chúng ta sẽ xem xét một số trường hợp nổi tiếng sau và tìm hiểu cách khắc phục chúng.

Lỗi bên trong

Loại InternalError được sử dụng khi một ngoại lệ xảy ra trong công cụ thời gian chạy JavaScript. Nó có thể có hoặc không thể chỉ ra sự cố với mã của bạn.

Thông thường, InternalError chỉ xảy ra trong hai trường hợp:

• Khi một bản vá hoặc một bản cập nhật cho thời gian chạy JavaScript mang một lỗi gây ra ngoại lệ (điều này rất hiếm khi xảy ra)
• Khi mã của bạn chứa các thực thể quá lớn đối với công cụ JavaScript (ví dụ: quá nhiều trường hợp chuyển đổi, bộ khởi tạo mảng quá lớn, quá nhiều đệ quy)

Cách tiếp cận thích hợp nhất để giải quyết lỗi này là xác định nguyên nhân thông qua thông báo lỗi và cấu trúc lại logic ứng dụng của bạn, nếu có thể, để loại bỏ khối lượng công việc tăng đột biến trên JavaScript engine.

URIError

URIError xảy ra khi một chức năng xử lý URI toàn cầu như decodeURIComponent được sử dụng bất hợp pháp. Nó thường chỉ ra rằng tham số được truyền đến cuộc gọi phương thức không tuân theo các tiêu chuẩn của URI và do đó không được phương thức phân tích cú pháp đúng cách.

Việc chẩn đoán những lỗi này thường dễ dàng vì bạn chỉ cần kiểm tra các đối số cho dị dạng.

EvalError

Một EvalError xảy ra khi một lỗi xảy ra với một lệnh gọi hàm eval() . Hàm eval() được sử dụng để thực thi mã JavaScript được lưu trữ trong chuỗi. Tuy nhiên, vì việc sử dụng hàm eval() rất không được khuyến khích do các vấn đề bảo mật và các đặc tả ECMAScript hiện tại không ném lớp EvalError nữa, nên loại lỗi này tồn tại đơn giản để duy trì khả năng tương thích ngược với mã JavaScript cũ.

Nếu bạn đang làm việc trên phiên bản JavaScript cũ hơn, bạn có thể gặp phải lỗi này. Trong mọi trường hợp, tốt nhất bạn nên điều tra mã được thực thi trong lệnh gọi hàm eval() để biết bất kỳ trường hợp ngoại lệ nào.

Tạo các loại lỗi tùy chỉnh

Mặc dù JavaScript cung cấp một danh sách đầy đủ các lớp loại lỗi để bao gồm cho hầu hết các trường hợp, bạn luôn có thể tạo một loại lỗi mới nếu danh sách không đáp ứng yêu cầu của bạn. Nền tảng của sự linh hoạt này nằm ở chỗ JavaScript cho phép bạn ném mọi thứ theo đúng nghĩa đen bằng lệnh throw .

Vì vậy, về mặt kỹ thuật, những tuyên bố này hoàn toàn hợp pháp:

throw 8 throw "An error occurred"

Tuy nhiên, việc ném một kiểu dữ liệu nguyên thủy không cung cấp thông tin chi tiết về lỗi, chẳng hạn như kiểu, tên của nó hoặc dấu vết ngăn xếp kèm theo. Để khắc phục điều này và chuẩn hóa quy trình xử lý lỗi, lớp Error đã được cung cấp. Nó cũng không được khuyến khích sử dụng các kiểu dữ liệu nguyên thủy trong khi ném các ngoại lệ.

Bạn có thể mở rộng lớp Error để tạo lớp lỗi tùy chỉnh của mình. Đây là một ví dụ cơ bản về cách bạn có thể làm điều này:

class ValidationError extends Error { constructor(message) { super(message); this.name = "ValidationError"; } }

Và bạn có thể sử dụng nó theo cách sau:

throw ValidationError("Property not found: name")

Và sau đó bạn có thể xác định nó bằng cách sử dụng từ khóa instanceof :

try { validateForm() // code that throws a ValidationError } catch (e) { if (e instanceof ValidationError) // do something else // do something else }

10 lỗi phổ biến nhất trong JavaScript

Bây giờ bạn đã hiểu các loại lỗi phổ biến và cách tạo các lỗi tùy chỉnh của mình, đã đến lúc xem xét một số lỗi phổ biến nhất mà bạn sẽ gặp phải khi viết mã JavaScript.

1. Dải ô chưa được giải quyết

Lỗi này xảy ra trong Google Chrome trong một số trường hợp khác nhau. Đầu tiên, nó có thể xảy ra nếu bạn gọi một hàm đệ quy và nó không kết thúc. Bạn có thể tự mình kiểm tra điều này trong Bảng điều khiển dành cho nhà phát triển Chrome:

Vì vậy, để giải quyết một lỗi như vậy, hãy đảm bảo xác định các trường hợp đường viền của hàm đệ quy của bạn một cách chính xác. Một lý do khác khiến lỗi này xảy ra là nếu bạn đã chuyển một giá trị nằm ngoài phạm vi tham số của hàm. Đây là một ví dụ:

Thông báo lỗi thường sẽ cho biết mã của bạn bị lỗi. Sau khi bạn thực hiện các thay đổi, nó sẽ được giải quyết.

2. Uncaught TypeError: Không thể đặt thuộc tính

Lỗi này xảy ra khi bạn đặt một thuộc tính trên một tham chiếu không xác định. Bạn có thể tái tạo sự cố với mã này:

var list list.count = 0

Đây là kết quả mà bạn sẽ nhận được:

Để khắc phục lỗi này, hãy khởi tạo tham chiếu với một giá trị trước khi truy cập các thuộc tính của nó. Đây là cách nó trông như thế nào khi được sửa:

3. Uncaught TypeError: Không thể đọc thuộc tính

Đây là một trong những lỗi thường xuyên xảy ra nhất trong JavaScript. Lỗi này xảy ra khi bạn cố gắng đọc một thuộc tính hoặc gọi một hàm trên một đối tượng không xác định. Bạn có thể tái tạo nó rất dễ dàng bằng cách chạy mã sau trong Bảng điều khiển dành cho nhà phát triển Chrome:

var func func.call()

Đây là kết quả:

Đối tượng không xác định là một trong nhiều nguyên nhân có thể gây ra lỗi này. Một nguyên nhân nổi bật khác của vấn đề này có thể là trạng thái khởi tạo không đúng cách trong khi hiển thị giao diện người dùng. Đây là một ví dụ trong thế giới thực từ một ứng dụng React:

import React, { useState, useEffect } from "react"; const CardsList = () => { const [state, setState] = useState(); useEffect(() => { setTimeout(() => setState({ items: ["Card 1", "Card 2"] }), 2000); }, []); return ( <> {state.items.map((item) => ( <li key={item}>{item}</li> ))} </> ); }; export default CardsList;

Ứng dụng bắt đầu với một vùng chứa trạng thái trống và được cung cấp một số mặt hàng sau 2 giây trễ. Độ trễ được đưa ra để bắt chước cuộc gọi mạng. Ngay cả khi mạng của bạn siêu nhanh, bạn vẫn sẽ phải đối mặt với độ trễ nhỏ do thành phần sẽ hiển thị ít nhất một lần. Nếu bạn cố gắng chạy ứng dụng này, bạn sẽ nhận được lỗi sau:

Điều này là do, tại thời điểm kết xuất, vùng chứa trạng thái là không xác định; do đó, không tồn tại items tài sản trên đó. Khắc phục lỗi này rất dễ dàng. Bạn chỉ cần cung cấp một giá trị mặc định ban đầu cho vùng chứa trạng thái.

// ... const [state, setState] = useState({items: []}); // ...

Bây giờ, sau độ trễ đã đặt, ứng dụng của bạn sẽ hiển thị đầu ra tương tự:

Cách khắc phục chính xác trong mã của bạn có thể khác, nhưng bản chất ở đây là luôn khởi tạo các biến của bạn đúng cách trước khi sử dụng chúng.

4. TypeError: ‘undefined’ không phải là một đối tượng

Lỗi này xảy ra trong Safari khi bạn cố gắng truy cập các thuộc tính của hoặc gọi một phương thức trên một đối tượng không xác định. Bạn có thể chạy mã tương tự từ phía trên để tự tạo lại lỗi.

Giải pháp cho lỗi này cũng giống nhau – hãy đảm bảo rằng bạn đã khởi tạo các biến của mình một cách chính xác và chúng không được xác định khi một thuộc tính hoặc phương thức được truy cập.

5. TypeError: null không phải là một đối tượng

Điều này, một lần nữa, tương tự như lỗi trước đó. Nó xảy ra trên Safari và sự khác biệt duy nhất giữa hai lỗi là lỗi này được ném ra khi đối tượng có thuộc tính hoặc phương thức đang được truy cập là null thay vì undefined . Bạn có thể tái tạo điều này bằng cách chạy đoạn mã sau:

var func = null func.call()

Đây là kết quả mà bạn sẽ nhận được:

Vì null là một giá trị được đặt rõ ràng thành một biến và không được JavaScript gán tự động. Lỗi này chỉ có thể xảy ra nếu bạn đang cố gắng truy cập vào một biến do chính bạn đặt null . Vì vậy, bạn cần phải truy cập lại mã của mình và kiểm tra xem logic mà bạn đã viết có đúng hay không.

6. TypeError: Không thể đọc thuộc tính ‘length’

Lỗi này xảy ra trong Chrome khi bạn cố đọc độ dài của một đối tượng null hoặc undefined . Nguyên nhân của vấn đề này tương tự như các vấn đề trước, nhưng nó xảy ra khá thường xuyên trong khi xử lý danh sách; do đó nó xứng đáng được đề cập đặc biệt. Đây là cách bạn có thể tái tạo sự cố:

Tuy nhiên, trong các phiên bản Chrome mới hơn, lỗi này được báo cáo là Uncaught TypeError: Cannot read properties of undefined . Bây giờ nó trông như thế này:

Cách khắc phục, một lần nữa, là đảm bảo rằng đối tượng có độ dài mà bạn đang cố truy cập tồn tại và không được đặt thành null .

7. TypeError: ‘undefined’ không phải là một hàm

Lỗi này xảy ra khi bạn cố gắng gọi một phương thức không tồn tại trong tập lệnh của bạn hoặc nó có nhưng không thể được tham chiếu trong ngữ cảnh gọi. Lỗi này thường xảy ra trong Google Chrome và bạn có thể giải quyết nó bằng cách kiểm tra dòng mã gây ra lỗi. Nếu bạn tìm thấy lỗi đánh máy, hãy sửa lỗi đó và kiểm tra xem nó có giải quyết được sự cố của bạn hay không.

Nếu bạn đã sử dụng từ khóa tự tham chiếu this trong mã của mình, lỗi này có thể phát sinh nếu từ khóa this không được liên kết thích hợp với ngữ cảnh của bạn. Hãy xem xét đoạn mã sau:

function showAlert() { alert("message here") } document.addEventListener("click", () => { this.showAlert(); })

Nếu bạn thực thi đoạn mã trên, nó sẽ tạo ra lỗi mà chúng ta đã thảo luận. Điều này xảy ra vì hàm ẩn danh được truyền dưới dạng trình xử lý sự kiện đang được thực thi trong ngữ cảnh của document .

Ngược lại, hàm showAlert được định nghĩa trong ngữ cảnh của window .

Để giải quyết vấn đề này, bạn phải chuyển tham chiếu thích hợp đến hàm bằng cách liên kết nó với phương thức bind() :

document.addEventListener("click", this.showAlert.bind(this))

8. ReferenceError: sự kiện không được xác định

Lỗi này xảy ra khi bạn cố gắng truy cập một tham chiếu không được xác định trong phạm vi gọi. Điều này thường xảy ra khi xử lý các sự kiện vì chúng thường cung cấp cho bạn một tham chiếu được gọi là event trong hàm gọi lại. Lỗi này có thể xảy ra nếu bạn quên xác định đối số sự kiện trong các tham số của hàm hoặc viết sai chính tả.

Lỗi này có thể không xảy ra trong Internet Explorer hoặc Google Chrome (vì IE cung cấp biến sự kiện chung và Chrome tự động đính kèm biến sự kiện vào trình xử lý), nhưng nó có thể xảy ra trong Firefox. Vì vậy, bạn nên để ý những lỗi nhỏ như vậy.

9. TypeError: Gán cho biến hằng số

Đây là một lỗi phát sinh do bất cẩn. Nếu bạn cố gắng gán một giá trị mới cho một biến hằng số, bạn sẽ gặp kết quả như vậy:

Mặc dù có vẻ dễ sửa ngay bây giờ, nhưng hãy tưởng tượng hàng trăm khai báo biến như vậy và một trong số chúng được định nghĩa nhầm thành const thay vì let ! Không giống như các ngôn ngữ kịch bản khác như PHP, có sự khác biệt tối thiểu giữa phong cách khai báo hằng và biến trong JavaScript. Vì vậy, trước hết, bạn nên kiểm tra các khai báo của mình khi gặp lỗi này. Bạn cũng có thể gặp phải lỗi này nếu bạn quên rằng tham chiếu đã nói là một hằng số và sử dụng nó như một biến. Điều này cho thấy sự bất cẩn hoặc một sai sót trong logic của ứng dụng của bạn. Đảm bảo kiểm tra điều này khi cố gắng khắc phục sự cố này.

10. (không xác định): Lỗi tập lệnh

Lỗi tập lệnh xảy ra khi tập lệnh của bên thứ ba gửi lỗi đến trình duyệt của bạn. Theo sau lỗi này là (không xác định) vì tập lệnh của bên thứ ba thuộc về miền khác với ứng dụng của bạn. Trình duyệt ẩn các chi tiết khác để ngăn rò rỉ thông tin nhạy cảm từ tập lệnh của bên thứ ba.

Bạn không thể giải quyết lỗi này nếu không biết chi tiết đầy đủ. Đây là những gì bạn có thể làm để biết thêm thông tin về lỗi:

1. Thêm thuộc tính crossorigin trong thẻ script.
2. Đặt đúng tiêu đề Access-Control-Allow-Origin trên máy chủ lưu trữ tập lệnh.
3. [Tùy chọn] Nếu bạn không có quyền truy cập vào máy chủ lưu trữ tập lệnh, bạn có thể xem xét sử dụng proxy để chuyển tiếp yêu cầu của bạn đến máy chủ và quay lại máy khách với các tiêu đề chính xác.

Sau khi bạn có thể truy cập thông tin chi tiết của lỗi, bạn có thể thiết lập để khắc phục sự cố, có thể xảy ra với thư viện của bên thứ ba hoặc mạng.

Cách xác định và ngăn ngừa lỗi trong JavaScript

Mặc dù các lỗi được thảo luận ở trên là phổ biến nhất và thường xuyên nhất trong JavaScript, bạn sẽ gặp phải, chỉ dựa vào một vài ví dụ không bao giờ là đủ. Điều quan trọng là phải hiểu cách phát hiện và ngăn chặn bất kỳ loại lỗi nào trong một ứng dụng JavaScript trong khi phát triển nó. Đây là cách bạn có thể xử lý lỗi trong JavaScript.

Ném và bắt lỗi theo cách thủ công

Cách cơ bản nhất để xử lý các lỗi được đưa ra theo cách thủ công hoặc trong thời gian chạy là bắt chúng. Giống như hầu hết các ngôn ngữ khác, JavaScript cung cấp một tập hợp các từ khóa để xử lý lỗi. Điều cần thiết là phải biết chuyên sâu về từng thứ trước khi bạn bắt đầu xử lý các lỗi trong ứng dụng JavaScript của mình.

ném

Từ khóa đầu tiên và cơ bản nhất của bộ này là throw . Rõ ràng, từ khóa ném được sử dụng để ném lỗi nhằm tạo ngoại lệ trong thời gian chạy JavaScript theo cách thủ công. Chúng ta đã thảo luận về điều này trước đó trong phần này và đây là ý chính về ý nghĩa của từ khóa này:

• Bạn có thể throw bất kỳ thứ gì, bao gồm số, chuỗi và các đối tượng Error .
• Tuy nhiên, không nên ném các kiểu dữ liệu nguyên thủy như chuỗi và số vì chúng không mang thông tin gỡ lỗi về lỗi.
• Ví dụ: throw TypeError("Please provide a string")

thử

Từ khóa try được sử dụng để chỉ ra rằng một khối mã có thể tạo ra một ngoại lệ. Cú pháp của nó là:

try { // error-prone code here }

Điều quan trọng cần lưu ý là khối catch phải luôn theo sau khối try để xử lý lỗi một cách hiệu quả.

chụp lấy

Từ khóa catch được sử dụng để tạo khối catch. Khối mã này chịu trách nhiệm xử lý các lỗi mà khối try trailing mắc phải. Đây là cú pháp của nó:

catch (exception) { // code to handle the exception here }

Và đây là cách bạn triển khai các khối try và catch với nhau:

try { // business logic code } catch (exception) { // error handling code }

Không giống như C ++ hoặc Java, bạn không thể nối nhiều khối catch vào một khối try trong JavaScript. Điều này có nghĩa là bạn không thể làm điều này:

try { // business logic code } catch (exception) { if (exception instanceof TypeError) { // do something } } catch (exception) { if (exception instanceof RangeError) { // do something } }

Thay vào đó, bạn có thể sử dụng câu lệnh if...else hoặc câu lệnh trường hợp chuyển đổi bên trong khối lệnh bắt đơn để xử lý tất cả các trường hợp lỗi có thể xảy ra. Nó sẽ trông như thế này:

try { // business logic code } catch (exception) { if (exception instanceof TypeError) { // do something } else if (exception instanceof RangeError) { // do something else } }

cuối cùng

Từ khóa finally được sử dụng để xác định một khối mã được chạy sau khi một lỗi đã được xử lý. Khối này được thực thi sau khi thử và các khối bắt.

Ngoài ra, khối cuối cùng sẽ được thực thi bất kể kết quả của hai khối còn lại. Điều này có nghĩa là ngay cả khi khối catch không thể xử lý lỗi hoàn toàn hoặc lỗi được đưa vào khối catch, trình thông dịch sẽ thực thi mã trong khối cuối cùng trước khi chương trình bị treo.

Để được coi là hợp lệ, khối try trong JavaScript cần được theo sau bởi khối catch hoặc khối cuối cùng. Nếu không có bất kỳ điều nào trong số đó, trình thông dịch sẽ tạo ra một Lỗi cú pháp. Do đó, hãy đảm bảo tuân theo các khối thử của bạn với ít nhất một trong hai khối khi xử lý lỗi.

Xử lý lỗi trên toàn cầu với phương pháp onerror ()

Phương onerror() có sẵn cho tất cả các phần tử HTML để xử lý bất kỳ lỗi nào có thể xảy ra với chúng. Ví dụ: nếu thẻ img không thể tìm thấy hình ảnh có URL được chỉ định, nó sẽ kích hoạt phương thức onerror để cho phép người dùng xử lý lỗi.

Thông thường, bạn sẽ cung cấp một URL hình ảnh khác trong lệnh gọi onerror để thẻ img quay trở lại. Đây là cách bạn có thể làm điều đó thông qua JavaScript:

const image = document.querySelector("img") image.onerror = (event) => { console.log("Error occurred: " + event) }

Tuy nhiên, bạn có thể sử dụng tính năng này để tạo cơ chế xử lý lỗi chung cho ứng dụng của mình. Đây là cách bạn có thể làm điều đó:

window.onerror = (event) => { console.log("Error occurred: " + event) }

Với trình xử lý sự kiện này, bạn có thể loại bỏ nhiều khối try...catch nằm xung quanh mã của bạn và tập trung xử lý lỗi của ứng dụng tương tự như xử lý sự kiện. Bạn có thể đính kèm nhiều trình xử lý lỗi vào cửa sổ để duy trì Nguyên tắc Trách nhiệm Đơn lẻ từ các nguyên tắc thiết kế SOLID. Trình thông dịch sẽ quay vòng qua tất cả các trình xử lý cho đến khi nó đến trình xử lý thích hợp.

Vượt qua lỗi thông qua cuộc gọi lại

Trong khi các hàm tuyến tính và đơn giản cho phép việc xử lý lỗi vẫn đơn giản, các lệnh gọi lại có thể làm phức tạp thêm vấn đề.

Hãy xem xét đoạn mã sau:

const calculateCube = (number, callback) => { setTimeout(() => { const cube = number * number * number callback(cube) }, 1000) } const callback = result => console.log(result) calculateCube(4, callback)

Hàm trên thể hiện một điều kiện không đồng bộ, trong đó một hàm mất một khoảng thời gian để xử lý các hoạt động và trả về kết quả sau đó với sự trợ giúp của một lệnh gọi lại.

Nếu bạn cố gắng nhập một chuỗi thay vì 4 trong lệnh gọi hàm, kết quả là bạn sẽ nhận được NaN .

Điều này cần phải được xử lý đúng cách. Đây là cách thực hiện:

const calculateCube = (number, callback) => { setTimeout(() => { if (typeof number !== "number") throw new Error("Numeric argument is expected") const cube = number * number * number callback(cube) }, 1000) } const callback = result => console.log(result) try { calculateCube(4, callback) } catch (e) { console.log(e) }

Điều này sẽ giải quyết vấn đề một cách lý tưởng. Tuy nhiên, nếu bạn thử chuyển một chuỗi vào lệnh gọi hàm, bạn sẽ nhận được như sau:

Ngay cả khi bạn đã triển khai khối try-catch trong khi gọi hàm, nó vẫn thông báo lỗi là không thể xảy ra. Lỗi được đưa ra sau khi khối bắt được thực thi do độ trễ thời gian chờ.

Điều này có thể xảy ra nhanh chóng trong các cuộc gọi mạng, khi có sự chậm trễ không mong muốn. Bạn cần đề cập đến các trường hợp như vậy trong khi phát triển ứng dụng của mình.

Dưới đây là cách bạn có thể xử lý lỗi đúng cách trong các lệnh gọi lại:

const calculateCube = (number, callback) => { setTimeout(() => { if (typeof number !== "number") { callback(new TypeError("Numeric argument is expected")) return } const cube = number * number * number callback(null, cube) }, 2000) } const callback = (error, result) => { if (error !== null) { console.log(error) return } console.log(result) } try { calculateCube('hey', callback) } catch (e) { console.log(e) }

Bây giờ, đầu ra trên bảng điều khiển sẽ là:

Điều này cho thấy rằng lỗi đã được xử lý thích hợp.

Xử lý lỗi trong lời hứa

Hầu hết mọi người có xu hướng thích những lời hứa để xử lý các hoạt động không đồng bộ. Lời hứa có một lợi thế khác – một lời hứa bị từ chối không chấm dứt kịch bản của bạn. Tuy nhiên, bạn vẫn cần triển khai một khối bắt để xử lý lỗi trong các hứa hẹn. Để hiểu điều này tốt hơn, chúng ta hãy viết lại hàm calculateCube() bằng Promises:

const delay = ms => new Promise(res => setTimeout(res, ms)); const calculateCube = async (number) => { if (typeof number !== "number") throw Error("Numeric argument is expected") await delay(5000) const cube = number * number * number return cube } try { calculateCube(4).then(r => console.log(r)) } catch (e) { console.log(e) }

Thời gian chờ từ mã trước đó đã được tách biệt thành hàm delay để hiểu. Nếu bạn cố gắng nhập một chuỗi thay vì 4, đầu ra mà bạn nhận được sẽ tương tự như sau:

Một lần nữa, điều này là do Promise ném lỗi sau khi mọi thứ khác đã hoàn thành việc thực thi. Giải pháp cho vấn đề này rất đơn giản. Chỉ cần thêm một lệnh gọi catch() vào chuỗi hứa như thế này:

calculateCube("hey") .then(r => console.log(r)) .catch(e => console.log(e))

Bây giờ đầu ra sẽ là:

Bạn có thể quan sát mức độ dễ dàng xử lý lỗi với các lời hứa. Ngoài ra, bạn có thể chuỗi khối finally() và lệnh gọi bổ sung mã sẽ chạy sau khi hoàn tất việc xử lý lỗi.

Ngoài ra, bạn cũng có thể xử lý lỗi trong lời hứa bằng cách sử dụng kỹ thuật truyền thống thử bắt đầu. Đây là cách cuộc gọi lời hứa của bạn sẽ trông như thế nào trong trường hợp đó:

try { let result = await calculateCube("hey") console.log(result) } catch (e) { console.log(e) } finally { console.log('Finally executed") }

Tuy nhiên, điều này chỉ hoạt động bên trong một hàm không đồng bộ. Do đó, cách ưu tiên nhất để xử lý lỗi trong các lời hứa là catch chuỗi và finally là lệnh gọi hứa.

ném / bắt vs onerror () vs Callbacks vs Promises: Cái nào là tốt nhất?

Với bốn phương pháp tùy ý sử dụng, bạn phải biết cách chọn phương pháp thích hợp nhất trong bất kỳ trường hợp sử dụng nào. Đây là cách bạn có thể tự quyết định:

ném / bắt

Bạn sẽ sử dụng phương pháp này hầu hết thời gian. Đảm bảo thực hiện các điều kiện cho tất cả các lỗi có thể xảy ra bên trong khối bắt của bạn và nhớ bao gồm khối cuối cùng nếu bạn cần chạy một số quy trình dọn dẹp bộ nhớ sau khối thử.

Tuy nhiên, quá nhiều khối try / catch có thể khiến mã của bạn khó duy trì. Nếu bạn thấy mình trong tình huống như vậy, bạn có thể muốn xử lý lỗi thông qua trình xử lý toàn cục hoặc phương thức hứa.

Khi quyết định giữa các khối try / catch không đồng bộ và catch() của statement, bạn nên đi với các khối try / catch không đồng bộ vì chúng sẽ làm cho mã của bạn tuyến tính và dễ gỡ lỗi.

onerror ()

Tốt nhất bạn nên sử dụng phương thức onerror() khi bạn biết rằng ứng dụng của mình phải xử lý nhiều lỗi và chúng có thể nằm rải rác khắp cơ sở mã. Phương thức onerror cho phép bạn xử lý các lỗi như thể chúng chỉ là một sự kiện khác do ứng dụng của bạn xử lý. Bạn có thể xác định nhiều trình xử lý lỗi và đính kèm chúng vào cửa sổ ứng dụng của bạn trong lần hiển thị ban đầu.

Tuy nhiên, bạn cũng phải nhớ rằng phương thức onerror() có thể khó thiết lập một cách không cần thiết trong các dự án nhỏ hơn với phạm vi lỗi ít hơn. Nếu bạn chắc chắn rằng ứng dụng của mình sẽ không gặp quá nhiều lỗi, thì phương pháp ném / bắt truyền thống sẽ phù hợp nhất với bạn.

Gọi lại và lời hứa

Xử lý lỗi trong lệnh gọi lại và lời hứa khác nhau do cấu trúc và thiết kế mã của chúng. Tuy nhiên, nếu bạn chọn giữa hai điều này trước khi bạn viết mã của mình, thì tốt nhất là bạn nên đi kèm với những lời hứa.

Điều này là do các hứa hẹn có một cấu trúc sẵn có để xâu chuỗi một khối catch() và một khối finally() để dễ dàng xử lý lỗi. Phương pháp này dễ dàng và sạch sẽ hơn so với việc xác định các đối số bổ sung / sử dụng lại các đối số hiện có để xử lý lỗi.

Theo dõi các thay đổi với kho lưu trữ Git

Nhiều lỗi thường phát sinh do các lỗi thủ công trong cơ sở mã. Trong khi phát triển hoặc gỡ lỗi mã của bạn, cuối cùng bạn có thể thực hiện các thay đổi không cần thiết có thể gây ra các lỗi mới xuất hiện trong cơ sở mã của bạn. Kiểm tra tự động là một cách tuyệt vời để kiểm tra mã của bạn sau mỗi lần thay đổi. Tuy nhiên, nó chỉ có thể cho bạn biết nếu có điều gì đó không ổn. Nếu bạn không thường xuyên sao lưu mã của mình, bạn sẽ mất thời gian cố gắng sửa một hàm hoặc một tập lệnh đang hoạt động tốt trước đó.

Đây là nơi mà git đóng vai trò của nó. Với một chiến lược cam kết phù hợp, bạn có thể sử dụng lịch sử git của mình như một hệ thống sao lưu để xem mã của bạn khi nó phát triển trong quá trình phát triển. Bạn có thể dễ dàng duyệt qua các cam kết cũ hơn của mình và tìm ra phiên bản của hàm hoạt động tốt trước đây nhưng vẫn gặp lỗi sau một thay đổi không liên quan.

Sau đó, bạn có thể khôi phục mã cũ hoặc so sánh hai phiên bản để xác định điều gì đã xảy ra. Các công cụ phát triển web hiện đại như GitHub Desktop hoặc GitKraken giúp bạn hình dung những thay đổi này song song với nhau và nhanh chóng tìm ra những sai lầm.

Một thói quen có thể giúp bạn mắc ít lỗi hơn là chạy đánh giá mã bất cứ khi nào bạn thực hiện một thay đổi quan trọng đối với mã của mình. Nếu đang làm việc theo nhóm, bạn có thể tạo một yêu cầu kéo và nhờ một thành viên trong nhóm xem xét kỹ lưỡng. Điều này sẽ giúp bạn sử dụng cặp mắt thứ hai để phát hiện ra bất kỳ lỗi nào mà bạn có thể mắc phải.

Các phương pháp hay nhất để xử lý lỗi trong JavaScript

Các phương pháp được đề cập ở trên là đủ để giúp bạn thiết kế một phương pháp xử lý lỗi mạnh mẽ cho ứng dụng JavaScript tiếp theo của bạn. Tuy nhiên, tốt nhất là bạn nên ghi nhớ một số điều trong khi thực hiện chúng để đạt được hiệu quả tốt nhất trong việc sửa lỗi của bạn. Dưới đây là một số lời khuyên để giúp bạn.

1. Sử dụng lỗi tùy chỉnh khi xử lý ngoại lệ hoạt động

Chúng tôi đã sớm giới thiệu các lỗi tùy chỉnh trong hướng dẫn này để cung cấp cho bạn ý tưởng về cách tùy chỉnh việc xử lý lỗi cho trường hợp duy nhất của ứng dụng của bạn. Bạn nên sử dụng lỗi tùy chỉnh bất cứ khi nào có thể thay vì lớp Error chung chung vì nó cung cấp thêm thông tin theo ngữ cảnh cho môi trường gọi về lỗi.

Trên hết, lỗi tùy chỉnh cho phép bạn kiểm duyệt cách hiển thị lỗi đối với môi trường gọi. Điều này có nghĩa là bạn có thể chọn ẩn các chi tiết cụ thể hoặc hiển thị thông tin bổ sung về lỗi khi nào và khi nào bạn muốn.

Bạn có thể định dạng nội dung lỗi theo nhu cầu của mình. Điều này cho phép bạn kiểm soát tốt hơn cách giải thích và xử lý lỗi.

2. Không nuốt bất kỳ trường hợp ngoại lệ nào

Ngay cả những nhà phát triển cao cấp nhất cũng thường mắc một sai lầm mới – sử dụng các cấp độ ngoại lệ sâu trong mã của họ.

Bạn có thể gặp các tình huống trong đó bạn có một đoạn mã tùy chọn để chạy. Nếu nó hoạt động, tuyệt vời; nếu nó không, bạn không cần phải làm bất cứ điều gì về nó.

Trong những trường hợp này, bạn thường dễ dàng đặt mã này vào một khối thử và đính kèm một khối bắt trống vào đó. Tuy nhiên, bằng cách làm này, bạn sẽ để hở đoạn mã đó có thể gây ra bất kỳ loại lỗi nào và xử lý nó. Điều này có thể trở nên nguy hiểm nếu bạn có một cơ sở mã lớn và nhiều trường hợp cấu trúc quản lý lỗi kém như vậy.

Cách tốt nhất để xử lý các trường hợp ngoại lệ là xác định mức độ mà tất cả các trường hợp đó sẽ được xử lý và nâng cao chúng cho đến khi đó. Mức này có thể là bộ điều khiển (trong ứng dụng kiến trúc MVC) hoặc phần mềm trung gian (trong ứng dụng hướng máy chủ truyền thống).

Bằng cách này, bạn sẽ biết nơi bạn có thể tìm thấy tất cả các lỗi xảy ra trong ứng dụng của mình và chọn cách giải quyết chúng, ngay cả khi điều đó có nghĩa là không làm gì với chúng.

3. Sử dụng Chiến lược tập trung cho nhật ký và cảnh báo lỗi

Ghi lại một lỗi thường là một phần không thể thiếu trong việc xử lý nó. Những người không phát triển được chiến lược tập trung cho các lỗi ghi nhật ký có thể bỏ lỡ thông tin có giá trị về việc sử dụng ứng dụng của họ.

Nhật ký sự kiện của ứng dụng có thể giúp bạn tìm ra dữ liệu quan trọng về lỗi và giúp gỡ lỗi nhanh chóng. Nếu bạn có các cơ chế cảnh báo thích hợp được thiết lập trong ứng dụng của mình, bạn có thể biết khi nào có lỗi xảy ra trong ứng dụng của mình trước khi nó đến một phần lớn cơ sở người dùng của bạn.

Bạn nên sử dụng trình ghi nhật ký được tạo sẵn hoặc tạo một trình ghi nhật ký phù hợp với nhu cầu của bạn. Bạn có thể định cấu hình trình ghi nhật ký này để xử lý lỗi dựa trên các cấp độ của chúng (cảnh báo, gỡ lỗi, thông tin, v.v.) và một số trình ghi nhật ký thậm chí còn đi xa đến mức gửi nhật ký đến máy chủ ghi nhật ký từ xa ngay lập tức. Bằng cách này, bạn có thể xem logic của ứng dụng của bạn hoạt động như thế nào với những người dùng đang hoạt động.

4. Thông báo cho người dùng về lỗi một cách thích hợp

Một điểm tốt khác cần ghi nhớ khi xác định chiến lược xử lý lỗi của bạn là ghi nhớ người dùng.

Tất cả các lỗi ảnh hưởng đến hoạt động bình thường của ứng dụng của bạn phải hiển thị cảnh báo hiển thị cho người dùng để thông báo cho họ rằng đã xảy ra sự cố để người dùng có thể tìm ra giải pháp. Nếu bạn biết cách sửa lỗi nhanh chóng, chẳng hạn như thử lại thao tác hoặc đăng xuất và đăng nhập lại, hãy nhớ đề cập đến lỗi đó trong cảnh báo để giúp khắc phục trải nghiệm người dùng trong thời gian thực.

Trong trường hợp các lỗi không gây ra bất kỳ ảnh hưởng nào đến trải nghiệm người dùng hàng ngày, bạn có thể cân nhắc loại bỏ cảnh báo và ghi lại lỗi vào máy chủ từ xa để giải quyết sau.

5. Triển khai phần mềm trung gian (Node.js)

Môi trường Node.js hỗ trợ phần mềm trung gian để thêm chức năng cho các ứng dụng máy chủ. Bạn có thể sử dụng tính năng này để tạo phần mềm trung gian xử lý lỗi cho máy chủ của mình.

Lợi ích đáng kể nhất của việc sử dụng phần mềm trung gian là tất cả các lỗi của bạn đều được xử lý tập trung tại một nơi. Bạn có thể chọn bật / tắt thiết lập này cho mục đích thử nghiệm một cách dễ dàng.

Đây là cách bạn có thể tạo một phần mềm trung gian cơ bản:

const logError = err => { console.log("ERROR: " + String(err)) } const errorLoggerMiddleware = (err, req, res, next) => { logError(err) next(err) } const returnErrorMiddleware = (err, req, res, next) => { res.status(err.statusCode || 500) .send(err.message) } module.exports = { logError, errorLoggerMiddleware, returnErrorMiddleware }

Sau đó, bạn có thể sử dụng phần mềm trung gian này trong ứng dụng của mình như sau:

const { errorLoggerMiddleware, returnErrorMiddleware } = require('./errorMiddleware') app.use(errorLoggerMiddleware) app.use(returnErrorMiddleware)

Bây giờ bạn có thể xác định logic tùy chỉnh bên trong phần mềm trung gian để xử lý lỗi một cách thích hợp. Bạn không cần phải lo lắng về việc triển khai các cấu trúc xử lý lỗi riêng lẻ trên toàn bộ codebase của mình nữa.

6. Khởi động lại ứng dụng của bạn để xử lý lỗi lập trình viên (Node.js)

Khi ứng dụng Node.js gặp lỗi lập trình viên, họ có thể không nhất thiết phải đưa ra một ngoại lệ và cố gắng đóng ứng dụng. Những lỗi như vậy có thể bao gồm các vấn đề phát sinh do lỗi của lập trình viên, như tiêu thụ CPU cao, bộ nhớ bị phình ra hoặc rò rỉ bộ nhớ. Cách tốt nhất để xử lý những điều này là khởi động lại ứng dụng một cách duyên dáng bằng cách xử lý sự cố thông qua chế độ cụm Node.js hoặc một công cụ duy nhất như PM2. Điều này có thể đảm bảo rằng ứng dụng không gặp sự cố khi người dùng thực hiện hành động, mang lại trải nghiệm người dùng tồi tệ.

7. Nắm bắt tất cả các trường hợp ngoại lệ chưa được ghi nhận (Node.js)

Bạn không bao giờ có thể chắc chắn rằng mình đã giải quyết mọi lỗi có thể xảy ra trong ứng dụng của mình. Do đó, điều cần thiết là phải triển khai chiến lược dự phòng để bắt tất cả các trường hợp ngoại lệ chưa được đề xuất khỏi ứng dụng của bạn.

Đây là cách bạn có thể làm điều đó:

process.on('uncaughtException', error => { console.log("ERROR: " + String(error)) // other handling mechanisms })

Bạn cũng có thể xác định xem lỗi xảy ra là ngoại lệ tiêu chuẩn hay lỗi hoạt động tùy chỉnh. Dựa trên kết quả, bạn có thể thoát khỏi quá trình và khởi động lại nó để tránh các hành vi không mong muốn.

8. Nắm bắt tất cả các từ chối lời hứa chưa được xử lý (Node.js)

Tương tự như cách bạn không bao giờ có thể bao gồm tất cả các trường hợp ngoại lệ có thể xảy ra, khả năng cao là bạn có thể bỏ lỡ việc xử lý tất cả những lời hứa có thể bị từ chối. Tuy nhiên, không giống như các trường hợp ngoại lệ, việc từ chối lời hứa không gây ra lỗi.

Vì vậy, một lời hứa quan trọng đã bị từ chối có thể trượt qua như một lời cảnh báo và khiến ứng dụng của bạn có khả năng gặp phải hành vi không mong muốn. Do đó, điều quan trọng là phải triển khai một cơ chế dự phòng để xử lý việc từ chối lời hứa.

Đây là cách bạn có thể làm điều đó:

const promiseRejectionCallback = error => { console.log("PROMISE REJECTED: " + String(error)) } process.on('unhandledRejection', callback)

Bản tóm tắt

Giống như bất kỳ ngôn ngữ lập trình nào khác, lỗi xảy ra khá thường xuyên và tự nhiên trong JavaScript. Trong một số trường hợp, bạn thậm chí có thể cần cố ý ném lỗi để chỉ ra phản hồi chính xác cho người dùng của mình. Do đó, hiểu biết về giải phẫu và các loại của chúng là rất quan trọng.

Hơn nữa, bạn cần được trang bị các công cụ và kỹ thuật phù hợp để xác định và ngăn chặn các lỗi gỡ xuống ứng dụng của bạn.

Trong hầu hết các trường hợp, một chiến lược vững chắc để xử lý lỗi với việc thực thi cẩn thận là đủ cho tất cả các loại ứng dụng JavaScript.

Có bất kỳ lỗi JavaScript nào khác mà bạn vẫn chưa thể giải quyết không? Bất kỳ kỹ thuật nào để xử lý lỗi JS một cách xây dựng? Cho chúng tôi biết trong các ý kiến dưới đây!