What are the best practices for JavaScript error handling?_问答_开发者

I'm looking to start making my JavaScript a bit more error proof, and I'm finding plenty of documentation on using try, catch, finally, and throw, but I'm not finding a ton of advice from experts on when and where to throw errors.

Should every piece of code be wrapped in a try/catch?
Is there more advice like this on at what point errors ought to be caught?
Are there disadvantages to raising errors instead of having code fail silently in production?
This has been touched on on SO as far as implementati开发者_Python百科ons, but have server-logging JS errors an effective strategy?
Anything else I ought to know, regarding trapping errors in my application?

I'm also completely game for hearing of books that have great chapters or in-depth explanations of error-handling. Eloquent JavaScript touches on the matter, but isn't very prescriptive or opinionated about the issue.

Thanks for any advice you can give!

An immensely interesting set of slides on Enterprise JavaScript Error Handling can be found at https://web.archive.org/web/20140126104824/http://www.devhands.com/2008/10/javascript-error-handling-and-general-best-practices/

In short it summarizes:

Assume your code will fail
Log errors to the server
You, not the browser, handle errors
Identify where errors might occur
Throw your own errors
Distinguish fatal versus non-fatal errors
Provide a debug mode

The slides go into much more detail and most probably will give you some direction.

EDIT:

The presentation mentioned above can be found here: https://www.slideshare.net/nzakas/enterprise-javascript-error-handling-presentation

Nicholas Zakas of Yahoo! fame did a talk on Enterprise Error Handling (slides) at Ajax Experience 2008, in which he proposed something like this:

function log(sev,msg) {
    var img = new Image();
    img.src = "log.php?sev=" +
        encodeURIComponent(sev) +
        "&msg=" + encodeURIComponent(msg);
}

// usage
log(1, "Something bad happened.")

// Auto-log uncaught JS errors
window.onerror = function(msg, url, line) {
    log(1, msg);
    return true;
}

A year later, Nicholas Zakas posted an update on his blog which included a clever pattern to inject error handling code automatically on your production environment (using aspect-oriented programming).

When you start logging window.error calls, you're going to notice two things:

If your site is fairly complex, you're going to log a lot of errors
You'll be seeing a bunch of useless "window.error in undefined:0" messages

Reducing the torrent of log entries is as simple as testing for severity and/or a random number before logging to the server:

function log(sev,msg) {
    if (Math.random() > 0.1) return; // only log some errors

    var img = new Image();
    img.src = "log.php?sev=" +
        encodeURIComponent(sev) +
        "&msg=" + encodeURIComponent(msg);
}

Handling the useless window.error in undefined:0 errors depends on your site architecture, but can try identifying all Ajax calls and throwing an exception when something fails (possibly returning a stack trace using stacktrace.js).

IHMO, you should use error handling in javascript like you do in several other languages (AFAIK: Python, Java).

For better readability (and probably better performance, even though I am not sure it has a really big impact), you should use the try / catch block mostly on the following cases :

The part of the code you want to wrap is a key part of the whole algorithm. If it fails, it could :
- create errors on the next part of the codes (e.g. because a var is missing...)
- make the page not look what expected (impact on content or css)
- make the results appear strange to the user (impact on the code behavior)
You know that the code you are writing is not compatible with every browser
You planned that the code may fail (because there is no other way to check that it should work by if...then... blocks)
And also when you want to debug without bothering the final user

Eventually, javascript experts may have other elements to give.

my 2 cents to the box,

Regards,

Max

In addition to the other answers: one important thing is to use context data available in JavaScript error objects and in the window.onerror function parameters.

Things like the stacktrace (errorObject.stack), the filename, the line number and the column number. Note that each browser has some differences...so do your best effort to get nice errors.

There can even be problems with the console object itself. I use a custom window.onerror function inspired by this one and a special function to trace any given standard error object inspired by this code.

Another good point is to include the version of your web application somewhere close to the stacktrace (for quick and safe copy and pasting). You may also show errors more aggressively (alert...) in development mode as developers will not constantly monitor the browser console and may not see some of the problems.

Also use avoid using throw 'My message', use throw new Error('My message'), you can even have custom errors, read this article.

Always add some context to the errors (the version, the id of the object, some custom message, ...) and also make sure you make a distinction between external errors (some external data or circumstance made your system fail) and internal errors/assertions (your own system messed up), read about 'Design by contract'.

Here is a guide.

Also think about using general error handling like interceptors your libs and frameworks:

jQuery
Angular 1.x and for http
Angular 2.x
Your new dope framework here ...

I created script for that. It blocking all console commands except items mentioned in allow list, or block everything in blocklist. Works good even with colored console logs.

https://github.com/iiic/consoleFilter.js