Using try…catch…finally in JavaScript, follow up

The last post was an overview of how developers use try…catch. Here’s a quick overview so you don’t have to click back.

Not too long ago, try…catch wasn’t used much in JavaScript. The only time where I was encouraged to use try…catch blocks was where we were using outside data. I was told not to do this for three reasons, 1) it was ugly (this is an inadequate reason alone, but we’ll discuss it anyway), 2) it wasn’t optimized for performance, and 3) if something you did was asynchronous (gets executed or returned later) errors wouldn’t be handled. These flaws have been overcome since the bad old days and we’ll be discussing this in the next part. – Earlier post about try catch in JavaScript

It’s not ugly. A handful of developers think try…catch is ugly. Wow, that’s not very nice. The idea of “pretty code” confuses “easy to read and manage code” with code that looks good from far away. Usually this means short variable names and lines, not too much deep indentation, simple control flow structures, and short blocks. Some of these traits do make it easier to read and manage code, but often times this doesn’t come from the right place. A little over a decade ago, the web was all the rage with servers using Python and Ruby. Very different languages, but both languages lend themselves to both of these concepts. Many useful features were built into these core languages and their frameworks and going back to JavaScript in the browser could be jarring with all those long object names, c-like syntax, and extra symbols. I’m going to be honest, I don’t like this reason. You can have easy to read code that’s ugly and vice-versa. I am an amicable polyglot. I like all these languages.

It’s optimized. People used to say it’s not optimized. This was true at some point for Chrome but it is not the case any longer. Ultimately, the good use of try…catch…finally blocks are often more important for the overall app than optimization gains.

If we go back to 2013, we’ll see there was a moderate consensus against repeated use of try…catch.

Inside that question was a link to a jsperf, which saw several iterations. in particular saw that the difference between try catch in a loop and not in a loop was negligible. Even removing it altogether barely effects performance. If you goto revision 13, you can measure various ways of doing a try…catch. There, you’ll see that other things impact performance more than whether or not you’re using try…catch.

It’s good at working with asynchronous stuff. For real. It’s a synchronous block. Just like all blocks in JavaScript. Each expression gets evaluated and it moves on. If there’s a promise or something with a callback, the block will finish up before the execution of that asynchronous code. More so, due to the nature of “finally,” it may close up shop before the call backs are done. Well, it would have before. Now, you can use async functions! Prior to async functions and await, the pattern was to use the try…catch inside the callbacks. This was not optimal for two reason.

That’s a lot of layers, call backs, calls to other places.  Now lets use more modern syntax.

I don’t know about you, but to me this is much more straight forward, easier to read, and (dare, I say it?) not as ugly. Now, imagine this cleaner syntax when it’s nested, invoked, again and again. Less error handling code. Mixing this with other useful things to look into like currying and memoizing and you can create very concise error handling with clean and legibly.


Ultimately, try…catch works well, not only because of it’s built in functionality, but also because of it’s a universal, built in way to handle errors with modern JavaScript.

Further reading:


Written By StevenLacks