G+: This article is based on Node.js, but the …

David Coles
This article is based on Node.js, but the principles of error handling can apply to any language.

I'm particularly fond of this advice: "The best way to recover from programmer errors is to crash immediately."

(Programmer errors being "bugs" or mistakes in the code; not to be confused with operational errors that should be handled by good design)

Joyent | Error Handling

(+1's) 1
Matt Giuca
Good principle (separating the two types of error).

"You should know why this pattern [try { asyncOperation(); } catch ()] does not work to handle errors."

Um, tell that to 2015. async/await is a thing now* and it's a pure joy.

*Don't know about Node, but it's a think in JavaScript so I hope Node has it.

David Coles
It's usually a fundamental principle taught in most computer science classes, but I've seen plenty of people end up confused on the topic of error handling (e.g. logging every single (operational) error, trying to recover from programmer error or not having well defined behaviour on all plausible input). I also like that it enumerates a number of ways you can handle errors and some combinations that should well be avoided (e.g. don't mix sync/async error handling).

(I believe there may have been some push back against "promises" in Node.js by Joyent, but I've not found their reasoning yet - so far it looks like a nice model for asynchronous programming though you have to be careful with locks/explicitly handling errors).

I really need to catch up a bit on the state of modern JavaScript.

Matt Giuca
I think the design of JavaScript unnecessarily blurs these lines. Imagine a world where undefined variable errors or type errors just crashed the page. The JavaScript engine crashes and the entire web page gets replaced with a sad tab. It would make lousy websites significantly worse, but oh boy would it decrease the number of programmer errors in the wild.

Promises are old tech. Async/await is the new hotness built on top of promises.

Pre-promises code:

someAsyncOperation(function(result) {
// Do something with result.
}, function(error) {
// Report error.

With promises (and arrows):
someAsyncOperation().then(result => {
// Do something with result.
}).catch(error => {
// Report error.

Not a huge improvement, but great because you can chain promises, etc.

Enter async/await:

try {
result = await someAsyncOperation();
} catch (error) {
// Report error.
// Do something with result.


David Coles
Didn't that used to happen with IE4? You got the little red X and everything came screeching to a halt. (I'm not sure when that changed, but with the amount of assorted JavaScript on modern pages, I can see why that solution wouldn't scale).

Using async/await looks like a huge improvement over the callbacks (the later style looks at least superficially like Python's asyncio which I think also introduced async/await syntax recently). I'm honestly surprised a language like JavaScript went for so long without something like this. X'D