Navigating the JavaScript Error handling Minefield by Ben Vinegar
Every voice is named by two or more agreeing sources.
“URI error is interesting in that it can only, or at least today, it's only invoked if you try encode and decode URI”
URIError only occurs when encoding or decoding malformed URIs.
“That's not very useful. I agree.”
He feels creating custom errors without purpose is not useful.
“The stack trace is generated at the point that the error object is created. It's not generated at the point in which the error is thrown.”
Stack traces are captured when the Error is instantiated, not when it is thrown.
“you can just sort of copy that stack property from the original object that you're catching and copy it onto your new error.”
Copy the original error's stack to a new error to preserve the original trace.
“this is Chrome augmenting that error object with extra information so that you debugging like in the console has some more information to find the root of it.”
Chrome adds extra data to error objects in the console to aid debugging.
“no throw literal”
Enable an ESLint rule that forbids throwing literal values so only proper error objects are thrown.
“it was actually introduced in 1997”
The window.onerror global error handler has existed since 1997, making it a very old JavaScript feature.
“Same origin policy, if you're not familiar with it, is basically sort of this fundamental tenet of browser security that says, you know, content on one domain can't reach into another”
The same‑origin policy prevents a page on one domain from accessing data on another, protecting user privacy.
“Don't throw strings, please.”
Avoid throwing string literals as errors because they make debugging harder.
“I really encourage you to check out Sentry”
Ben suggests using Sentry as an error‑monitoring solution that works out of the box.