Async/await is great. Makes your code easier to read πŸ‘Œ But the error handling … oof πŸ™„

Yes try catch is great, it might even make your code easier to read. Combined with JavaScript’s modern block scoping it gives rise to the vile side of exception handling.

check this out πŸ‘‡

Say you’re using @lukeed05’s httpie to scream at a server.

A post request to a naughty server. But the naughty server says no.

What do you do? Add a try catch. Wanna handle those JavaScript errors and show a message to the user.

You’re talking to a naughty server and handling errors like you’re supposed to. πŸ‘

What about not errors? You can take the data and do something.

Oh no what just happened!? 😱

You’re getting a "Naughty server said no" error even though you made the mistake. You can’t just access properties on undefinedStuff. JavaScript doesn’t like that.

Blaming the server for your mistakes, tsk

Oh I know! We can move using data to after the catch block, right? That should work.

Nope. Now data isn’t defined because const { data } only works within that try block. πŸ€¦β€β™‚οΈ

You could solve that with a var, but that’s old school JavaScript and we all agreed we’d stop using it.

What about this?

This works. But pre-declaring your variables like it’s 1978? No thanks. That’s why variable hoisting was invented in the first place, lol.

You could wrap your code in another level of try/catch …

And that’s never ever going to get out of hand is it? πŸ˜…

I’m gonna be honest with you: There’s no solution. Not a nice one. Not in JavaScript.

Other languages let you catch specific error types. As far as I know, JavaScript doesn’t (can’t?) support that :/

We have stumbled upon the basic truth of exception handling

It sucks. It always sucks. Whichever way you do it, it’s going to make your head spin.

You see there’s 2 ways software can approach errors:

  1. Error passing
  2. Exceptions

Error passing

Error passing is what we used to do with JavaScript in the era of callbacks. Callbacks break try/catch for deep technical reasons so we stopped using them.

The logic behind error passing is simple: Every function can return an error, or a result.

Great in theory. Except now every function has to check for errors.. Our code looked like this:

1st argument out of a function is an error object, 2nd argument is the result. Check for errors, go into the error path, no errors, do the stuff.

Error handling spreads through your codebase like a virus.

All languages have this problem. Some on purpose, some by accident. I know Golang made the conscious decision to use error passing because exceptions are a mess and errors should be handled right away.

Luke proposes function wrappers to give your async/await code error passing superpowers.



🀨 I’m not convinced but I guess

Exceptions "improve" error passing

Many moons ago someone had the bright idea that hey error passing sucks, let’s use exceptions instead. Wikipedia says it was Lisp in the 1960s.

Something like this:

  1. Error handling sucks
  2. Passing errors around and staying vigilant at all times leads to bugs
  3. What if we had a sort of error context that handles it behind the scenes?

So instead of functions returning errors, they raise exceptions and hope for the best 🀞

When you raise an exception your code stops. The computer then goes back up through the entire call stack to find the nearest catch block.

That catch block handles your error and execution continues from there. NOT from where the error was raised.

This is crucial. It means that 90% of the time you’re writing happy path code and don’t have to worry about errors.

And somewhere in your code you make sure to handle all errors.

For example that’s how Ruby on Rails can make sure that no matter what you do, if all goes to shit, RoR itself will serve a beautiful 500 page telling the user what’s up.


Python does it great too. You never know what sort of error or exception some code might raise and you hope that someone somewhere will know how to handle it.

You focus on the good stuff.

JavaScript’s missing exception piece

JavaScript’s missing piece are exception types.

Take this Python code for example:

Beautiful ❀️

Write happy path code in one block, followed by a series of error handling code for different types of errors.

This works across function calls, across entire systems, it just works. It works really really well.

If you don’t handle the error, it bubbles up the stack. Someone will handle it.

When all goes to shit, the Python environment itself runs your code in a try/except of sorts so it can print an error message. ✌️

What can you do?

Give up. You’re already writing code. There’s your first mistake πŸ˜›

Error handling is always going to suck. I’m sorry.

But you can emulate the python/ruby/java/etc approach in JavaScript and make your life a little easier. You’ll have to coordinate with your team because there’s no language support, but something like this might work:

Of course then you have to set myType on every error you raise and that’s tedious too πŸ€”

Sorry that’s the best we can do. πŸ™ˆ

Five things Friday

As promised last week, here’s five cool things

The httpie library my favorite way to talk to servers from JavaScript. Really happy with it. Check out my twitter thread review of httpie

React Hooks are out. 🎣

Here’s a good overview from SebHastian

You can also read my twitter thread about hooks where I get panned for Doing It Wrong. Fun times.

This isn’t technical but it is amazing. @shl reflects on his failure to build a billion dollar company. Instead he built an amazing business that works. (Gumroad)

Michel Westrase whose name I can never spell right (he made MobX) writes a great article about UI as an afterthought

Enjoy your weekend ✌️


Learned something new? Want to improve your skills?

Join over 10,000 engineers just like you already improving their skills!

Here's how it works πŸ‘‡

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet πŸ“–right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

PS: You should also follow me on twitter πŸ‘‰ here.
It's where I go to shoot the shit about programming.