error-handling strategies in JavaScript

[othiym23]

Error-handling strategies in JavaScript

Forrest L Norvell, New Relic Nick Niemeir, New Relic

The gist

It doesn't matter how smart you are or how zealously you observe BDD, someday something weird is going to happen to your code and it's going to break. You're going to need to make it deal with being broken! JavaScript has some built-in tools for dealing with errors, but they have two big problems:

1. exceptions weren't really designed for dynamic languages, so they don't play nicely with just-in-time compilation, and
2. try/catch-based exception handling doesn't work at all in today's liberal utopian (asynchronous) void

Also, IE 6 is still a thing. Browsers do not make it easy to capture and display complete information about errors from JavaScript.

The gristle

We'll start with a brief overview of the methodology of error handling, framed in terms of what you WANT to do (recover and keep going) as opposed to what you OUGHT to do (shoot the process in the head and reload / display a message to the user and forcibly reload the page).

We'll go over the strategies available to you, with an approach that is agnostic to whether you're writing JavaScript on the client or the server:

synchronously

1. try/catch
2. error handlers on streams
3. return codes

   asynchronously

4. conventional Node async callbacks
5. promises

   globally

6. global error handlers (window.onerror / process.on('uncaughtException'))
7. domains and asyncListeners (maybe even domains2 if I can get a cogent enough description of it out of Bert)

We'll wrap it up with a brief discussion of practical considerations, like strategies for ensuring that errors make it out of the browser and back to you in a useful form, why throwing anything except Errors makes you a bad person, and just how badly robust error-handling will impair performance (spoiler: not unacceptably). It would be rad to do this in a workshoppy way, but at the very least it would be good to have a good half of the talk be interactive in such a way that we can elicit from the audience what their pain points are and work together to talk about how best to address them.

The grit

Nick and Forrest write JavaScript for New Relic. Who are we to tell you how to do a thing? Well, Forrest wrote a fairly substantial error tracer for Node as part of his work for New Relic (that eventually led to changes to Node 0.12), and Nick has been working on the same thing for the browser.

Forrest co-ran the workshop on domains at NodeConf 2013 but would really like to be known for more than just being "the domains guy". Nick has a very calm and soothing presence, especially after Forrest has been yammering on for a while.

[mikeal]

Would this apply to both frontend and backend error handling? It's my inclination to think it's more node focused but that's cause I know you :)

[othiym23]

Both, which in practice means I'd probably cede most of the time to @nrn because what he's doing with front-end stuff is way more interesting than my stuff, although I do have some asyncListener-related things to demo (including a browserify module that puts asyncListener in the browser some other folks are working on!).

My only concern is that this is a loooot of stuff to fit into 20 minutes. Hence the desire to have more emphasis on the front end and Nick.

[nrn]

I think there is a lot of stuff we could talk about that is universal in JavaScript, the pitfalls of synchronous exceptions in an asynchronous environment know no bounds.