Try…Catch…Finally Error Handling in JavaScript

Part 1, What is it? What is try...catch? Why use try...finally or try...catch...finally?

Finally. We can use try…catch.

Before we get into how this applies to todays JavaScript code in the next article, let’s review what try…catch…finally is and isn’t. What we won’t cover in this or the next part of this series is the scoping of try…catch. There’s some important stuff going on with try…catch…finally with block scopes. Because scope is another intermediate lesson in JavaScript itself, I’ve left it out.

We’re going to discuss what each part is and when to use it.

Errors and exceptions

In JavaScript, errors and exceptions are treated the same. They are pretty much the same except in name. JavaScript has Errors that are instances of the global Error object or an object that inherits from it. You can extend the global Error. The DOM has errors too, these are usually called exceptions, though in JavaScript, they are syntactically treated the same. User created errors are usually called exceptions. I’ll try to use Error in this article, because we’re discussing all Errors and Exceptions and that’s what JavaScript calls them.

What is try…catch…finally.

(Feel free to follow along in the console.)

A try block allow you to try to execute code that you’re not sure will work. A catch block follows the try block, it accepts an argument, which is the error thrown (It “catches” the thrown error, get it? I find the terminology convenient and amusing). Then, at last, we follow it with a finally block. I’m going to execute all of these example in an immediately invoked functional expression. The try requires at least a catch or a finally block.

Without try…catch, we have a couple problems.

  • Our code stops executing. We never see the “after” message.
  • We don’t get any information about the error, no stack trace (lines, functions, etc.).
  • We have no way of dealing with the error. Here we’re manually throwing the error, which can be desirable some times. Other times, code may throw an error synchronously. This means, the code will stop executing and it won’t be a feature, it’ll just be a problem.

Let’s try try…catch out.

What’s the difference when we run the try…catch?

  • The “after” gets run, even though we have an error thrown. The code after the block keeps executing.
  • We have more info about the error, we can view the stack trace. The debugging info can be really handy.
  • You can execute code after an error, using the information from that error. A library can provide important feedback to the developer, or you to yourself. You can also use the info in the error to decide what to do next; for example, if it’s a type error you can ask the user for different data.
  • You can execute code after an error, unrelated to what was in the try…catch block or at least the error.

Still following? Let’s review.

The try block lets you execute code and if there’s an error, your code can analyze the error, respond to the user, try something else, or just continue on. This is the basic control-flow pattern that we will build on to do even more with try…catch.

Breaking from other control-flow structures.

You may find yourself in a situation where you 1) may have an unexpected error, 2) want to respond to that error, but 3) don’t want to just continue on as normal. Here’s some patterns for that using try…catch


Here, we’re going to do something, and then return back if it’s successful, but return back after handling an error if there is one. This is probably the most straight forward use of return. If it works, we return from try, if it fails, we return from catch.

Notice, in all of these, the code after the try…catch block doesn’t run. You never see the console.log(‘after’) execute. In your real app, if both the try and catch return, you won’t put code after, because it’s confusing.

You can use the catch to return the error or return default data, you can also use the catch to gather other information the application may need.

Executing code after the try…catch block

But what if, sometimes, you’ll need to do something after the try…catch block? How does that work? When would you use it?

Here, the try block’s only purpose is to thrown an error if needed. If there’s an error, it is thrown inside of the try block and the catch returns the default, then returns before the code after executes. Functionally, this works with returning data or displaying data. You could return the or defaultData or do something with them. The upside of moving the rest of the code out of the try…catch, is that you keep the try…catch logic contained to that part where you may have bad data, there’s less nested code (which leads to fewer errors). If there’s any errors thrown in the part of the code outside of the try…catch block, then it will act as that normally would – that could be a pro or con, depending on what you want the application to do.

Finally, let’s talk about finally.

The finally block executes whether try finishes or an error is thrown. The stock answer online when I was reading this was “to clean up.” That might be true but it’s not helpful, and when you dig deeper, there’s a lot of people claiming that “finally” is the same as running code after the try…catch block.

  • Finally runs before the try…catch…finally block moves on to the next thing. Even if you return from catch or try.
  • Finally can be used to reduce repetition without introducing new functions. Here “cleaning up” may be removing a modal from view or closing a connection.

Never mind cleaning up, with or without catch, finally can keep a tidy set of process regardless of what else happens in the try…catch block and before anything else can break. Finally is where you’ll clear out any potential memory hogs, open connections, or UI loose ends.

Is that it? What else can try…catch be used for?

You’re not limited to use in functions, try…catch…finally can be used in other control flows, you can use them to safely continue or break a loop or inside conditionals.


Try – This is where you put code that might fail

Catch – this is where you handle exceptions, take corrective actions, or gather more information

Finally – this is where you put code that must be executed regardless of whether the try fails or not.

Code after the block – the app then continues on with it’s normal business.

Closing note.

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.

Written By StevenLacks