The saga of Javascript errors and async/await

We went full circle with error management in Javascript!

Long ago, before AJAX was a thing, JS was pretty much synchronous and linear. Still, we had to handle errors, so we used try/catch:

function divide(a, b) { return a / b; } try { divide(1, 0); } catch (error) { // uh, oh } 

But then Ajax came along, along with a lot of other async API's. We started using more callbacks for our error management:

const xhr = new XMLHttpRequest(); xhr.onreadystatechange = function (content) { /* ... */ }; xhr.onerror = function (error) { /* ... */ }; 

And then Node.JS came along, with a callback based API. Error handling was quickly turning into callback hell:

fs.readFile('foo.txt', function (error, fileContent) { fs.writeFile('bar.txt', fileContent, function (otherError) { // ... }); }); 

And then... Then we created Promise to make it more readable and consistent (apparently):

// Fetch full content of the first item found fetch('www.example.com/items') .then(response => response.json()) .then(response => fetch('www.example.com/items/' + response[0].id) ) .catch(error => { // Wait! Is this from the first or the second request? }); 

A bit better, but we still need sequential execution, and soon we get into promise hell.

async/await to the rescue

Okay, we need to fix this.
So we decided to introduce a new syntax that will internally wait for a promise resolution and clean up the code. async/await is the solution:

// Fetch full content of the first item found const items = await fetch('www.example.com/items') const firstItem = (await items.json())[0] const fullContent = await fetch('www.example.com/items/' + firstItem.id) 

But wait! What if the first or the second request fails?
Don't worry! We have a solution for that too!

Behold the full circle of errors: try/catch 😆

try { // Fetch full content of the first item found const items = await fetch('www.example.com/items') const firstItem = (await items.json())[0] const fullContent = await fetch('www.example.com/items/' + firstItem.id) } catch (error) { // Wait! Is this from the first or the second request? } 

Pitfalls, pitfalls everywhere!

Cool! Try/catch is now async. YAY!

But what happens if I forget to use await? Well, more errors for you!

If you actually want to return a promise from a function but still handle errors, it looks like this:

try { return fetchAndParse('www.example.com/items.json') } catch (error) { // synchronous errors end up here } 

Can you guess what happens if fetchAndParse returns a rejected promise?

function fetchAndParse() { return new Promise((resolve, reject) => { reject(new Error('Nope!')); }; } 

And the answer is: nothing. Your try/catch block won't do anything to catch that error.
Why? Because you need the magic word in front of the function call to "connect" the chain of promises:

try { return await fetchAndParse('www.example.com/items.json') } catch (error) { // the rejection error ends up here } 

See the difference? Subtle, but quite important!

Conclusion

So basically, if you want to use async/await, you need to wrap everything with try/catch, and you must ensure every single promise has an await in front of it.

Otherwise, JS will just ignore the errors and continue like nothing happened.