Unhandled promise rejection và lỗi đã bắt: công cụ theo dõi lỗi nhận được gì

Trong bài thử của mình, lỗi throw không ai bắt và promise rejection không ai xử lý đều đến được công cụ theo dõi lỗi, trừ request bị huỷ mà Belvador bỏ qua. Còn lỗi nào code đã bắt thì không, kể cả khi đã đưa vào console.error, trừ khi chính code đó tự báo. Và một rejection bằng thứ không phải Error đến nơi mà không có stack.

Ngày 26/10/2026, mình kiểm chuyện này với 14 kiểu lỗi, mỗi kiểu trên một trang mới trong Chromium 141, ba lần mỗi kiểu. Công cụ là SDK browser của Sentry để mặc định (@sentry/browser 10.76.2) và @belvador/browser 0.5.1 của chính mình, vốn được xây trên nó. Lần chạy nào cũng ra cùng một con số.

14 kiểu lỗi#

Mỗi kiểu chỉ vài dòng, giống những gì hay gặp trong code thật:

async function loadInvoice(): Promise<never> {  throw new Error("invoice load failed");}void loadInvoice();                                  // gọi mà không awaitloadInvoice().catch((e) => console.error(e));        // bắt rồi logloadInvoice().catch((e) => captureException(e));     // bắt rồi báovoid Promise.reject("invoice load failed");          // reject bằng một chuỗi

Chỗ hai SDK khác nhau thì khoảng số ghi cả hai. Những dòng đáng chú ý nhất là những dòng có số 0.

Đã bắt là không ai thấy#

Công cụ theo dõi lỗi nghe hai sự kiện của trình duyệt: error cho lỗi throw không ai bắt, và unhandledrejection, được gửi khi “a JavaScript Promise that has no rejection handler is rejected”, tức một promise bị reject mà không có handler nào. Một handler catch chính là rejection handler. Có nó rồi thì trình duyệt không còn gì để báo, và công cụ theo dõi lỗi cũng vậy.

console.error(e) không thay đổi điều đó. Nó ghi vào console trên trình duyệt của người dùng, nơi bạn sẽ không bao giờ đọc. Để mặc định, không SDK nào biến lệnh console thành event. Sentry có một integration phải tự bật cho việc đó; tuỳ chọn console của Belvador thì chỉ ghi breadcrumb.

Một khối try/catch bọc lệnh fetch, kèm console.error và một toast, là kiểu code quen thuộc. Trong bài thử, nó không gửi event nào. Nếu người dùng thấy được là có gì đó hỏng, hãy báo nó:

try {  await saveInvoice(draft);} catch (e) {  captureException(e);  toast.error("Không lưu được hoá đơn");}

Xử lý muộn vẫn bị tính là chưa xử lý#

Một promise bị reject, rồi 100 ms sau mới gắn .catch. Lúc đó trình duyệt đã bắn unhandledrejection, nên công cụ báo nó là chưa xử lý, handled: false, ở cả ba lần chạy.

Trình duyệt có báo lại sau đó. MDN mô tả rejectionhandled, được gửi “when a handler is attached to the promise after its rejection had caused an unhandledrejection event”, tức khi handler được gắn vào sau khi rejection đã gây ra unhandledrejection. Event mình đã nhận thì vẫn giữ nguyên, vẫn là handled: false. Nếu công cụ của bạn hiện những rejection mà code thật ra có xử lý, hãy tìm các promise được tạo sớm rồi mới xử lý sau, chẳng hạn một request bắt đầu trước khi dialog mở ra. Gắn handler trước lúc promise bị reject thì sẽ không có báo cáo nào.

Reject bằng Error, đừng bằng chuỗi#

Khi code reject bằng thứ không phải Error, không có stack nào để gửi, vì chỉ object Error mới mang stack: chuỗi, object thường và undefined đều đến nơi với 0 frame. Chuỗi bị throw trong timer cũng không khá hơn mấy, Sentry gửi 0 frame, Belvador gửi 1 frame là dòng đã throw. Thay cho stack, công cụ gửi một câu:

UnhandledRejection: Non-Error promise rejection captured with value: invoice load failedUnhandledRejection: Object captured as promise rejection with keys: code, detail

Message còn; lỗi đến từ đâu thì mất. Các trường của object thường được gửi kèm trong phần extra của event, điều này đáng để ý nếu object đó chứa dữ liệu người dùng. Cách sửa rất nhỏ: reject(new Error("invoice load failed", { cause: original })), còn với thư viện bạn không sửa được thì bọc lại ở chỗ bạn gọi nó.

Nên làm gì#

1. Tìm các khối catch chỉ ghi log. Báo những lỗi mà người dùng sẽ nhận ra.
2. Mọi throw và reject đều nên là Error. Luật lint giúp được: prefer-promise-reject-errors cho rejection, @typescript-eslint/only-throw-error cho giá trị bị throw.
3. Await hoặc xử lý promise ngay chỗ tạo ra nó, để handler gắn muộn không hiện thành lỗi chưa xử lý.
4. Quyết định xử lý request bị huỷ thế nào. Một AbortError do người dùng rời trang không phải bug; Belvador mặc định bỏ qua, Sentry thuần thì gửi.
5. Thử một lần ở chế độ production: gây một lỗi đã bắt và một lỗi không ai bắt, rồi xem cái nào đến nơi.

Belvador giúp ở đâu#

@belvador/browser báo lỗi không ai bắt và unhandled rejection ngay khi init chạy, bỏ qua request bị huỷ trừ khi bạn bật captureAborted, và để tắt việc bắt console. Hướng dẫn SDK trình duyệt liệt kê những gì nó báo, còn tuỳ chọn SDK nói về captureAborted và breadcrumb. Với app React, trang React có đầy đủ cách cài. Stack chỉ hữu ích khi trỏ được về source của bạn, và đó là điều bài source map trên production kiểm tra.

Đọc tiếp#

• Xử lý lỗi JavaScript trong ứng dụng do AI viết: lỗi thoát ra từ đâu
• Error boundary của React và lỗi async: thí nghiệm bắt được gì
• Source map trên production với Vite: mỗi cấu hình thực sự đưa gì vào bản build