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.

Javascript Fundamentals: Number Datatype Part II

ES2015/ES6 came with the built in datatypes that are really handy. They’re so handy, that they are part of a strong argument for using ES2015 and transpiling, along with Arrow Functions, block scope, destructuring, spread operators, and defaults. ES2015 includes the Number type. This is super handy for dealing with your numbers in a consistent way across different environments and, as you’ll see, even locales.

To review, last time we talked about the JavaScript Number type,  we talked about the Number object and it’s handy qualities, properties and methods. We talked about how the constructor worked: what gets when you use new Number(val).  We took a deep dive into the methods on the global Number. So we learned about using Number to check values to see if they’re compatible with numerical calculations. Number also exposes some of JavaScript’s number constants as properties, where different operating environments have proven difficult; where one environment may tolerate larger integers, Number.MAX_SAFE_INTEGER provides a standard way to check against a constant.

This time, we’re going to dive deep in to the instances of Number. We’re going to look at the method on Number.prototype. When we instantiate an instance of number by calling new Number(val), JavaScript is going to take the prototype on Number and attach it to our new number instance. We’re also going to discuss Number compatibility with native Math functions.

You can see all the methods on the Number Instance here.

We’re going to talk about the Number.prototype.toFixed and Number.prototype.toLocale. There’s other methods, but these two are likely why you’d create an instance in the first place.

Using Number.prototype.toFixed

This works the same way as the old toFixed, which lives on (lowercase) numbers.

Essentially, these two snippets do the same thing:

If we tried to implement a real program, you’d have a bunch of custom coded checking, formating and alternatives. With the Number type, we can easily implement a standardized way to check for values as we saw in the first part of this series.

To do this with a plain number, you’d either have more blocks or have to do some too-clever logical expressions. Either way, readability and maintainability goes down. Here, we have a number, we check it’s ability to be worked on with the object we’re going to instatiate from. It’s consistent, plain and (probably) fairly safe.

Number also allows you to fail gracefully without try/catch blocks.


If you work with an international audience, you can use Number to handle your localization and currency.

For instance, if you want a string formated for a known locale, you can do this.

In the case of number internationalization, you can also use the NumberFormat object as part of JavaScript’s Internationalization Object, Intl, if that’s appropriate.

This concept is foreign to many of us US based devs (pun intentional), but these skills are very valuable. Your ability to understand and work with localization (and accessibility) is a very marketable skill in some industries. Does everyone need to be a Localization Master? No, but I do recommend learning the basics of internationalization and localization.

Math and Numbers v. math and numbers v. JavaScript and Numbers

One of the points of confusion I’ve encountered while using Number over simple number values is the way the Number instance appears when you inspect it in developer tools. Consider the following:

This concern isn’t an issue outside of the console. When JavaScript expressions are evaluated or native JavaScript functions and methods are executed, the Number PrimitiveValue is automatically retrieved.




JavaScript Fundamentals: Number Datatype Part I

Every few weeks, I catch code where the programmer (sometimes me) is bending over backwards to try to solve a problem that ES6 (or sometimes even older versions of JavaScript) already solves. In fact, the interviewers who interviewed me for my current job, ask interviewees for a method on a built-in datatype that’s been in JavaScript for a long time. No one ever uses the built-in method, we all try to write it from scratch. That experience reminds me to always learn and refresh on the basics of your skill set. The Number type is new-ish, but is widely under utilized for some very common functionality. (It’s not the subject of the interview.)

The ES6 Number datatype. Keep in mind the Number and it’s methods are not available in Internet Explorer and mobile browsers (12% or so of users in December 2016) without shimming or transpiling. If you’re not shimming or transpiling for a professional app, you probably should because of browser compatibility and cross-browser inconsistencies; though there are exceptions depending on your audience and performance requirements of course.

The Number Object goes well with HTML5’s number.  There’s not a lot of use of this input because it’s ugly and confusing, but it’s something to keep in mind.

Otherwise, if you’re not sure the value is a number or not, you can use the Number constructor to explicitly and predictably cast it as an instance of Number.

The Constructor of the Number Object

In this example, we convert data from an unpredictable  source like a text input or AJAX response.

These result of using this will be mathematically consistent, but the convenience of using the Number datatype is most valuable to prevent the developer from having to think about math. So here’s some common uses:

This is great, it’s predictable: you’re going to get a Number Object and it’s either going to have a value of a number or “not a number.”

Numbers you can use

When you want to see if a value passed as an argument to a function is a usable number? Before ES6 you had the global isFinite function. You can still use it, but it’s hard to remember all of the built in globals, they’re more likely to get written over, but perfectly acceptable. I prefer using the new ones built on the Number object. I like code to be intentional and explicit. Further, there’s potential for JavaScript runtimes  to lack the window methods; for instance, NodeJS doesn’t have the window object, if you’re using window[method] notation, your code wouldn’t be reusable unless you account for global[method]. Native run times may eliminate global methods altogether, since they’re not as chained to the Browser API.

Here’s some examples of what you get using Number.isFinite(value):

The first thing you can do is use the Number constructor to explicitly recast strings consisting only of a number to a Number type.

So you can do something like this:

Using the number

If you want to work with that number like you would a number literal, you can get the value back by using the “valueOf” method.

You can use the “value” just as you would any number literal or trusted variable. Otherwise, you can use the “numberObject” (the instance of Number holding our value) and all of the methods that live on the instance (covered in future posts).

Other Global Number methods

Number also includes methods for checking a number to see if it is an integer and safe integer.

Number also has methods for the globals isNaN, parseInt, and parseFloat.

Number’s you can’t lose: Constants

My audience is unlikely to use these Constant properties, but here they are:

Next time, we’ll look at some of the instance methods on the global Number object.

Should you upgrade to jQuery 3?

I recently sent out this suggestion to some of my clients. From my client’s perspectives, investing in upgrading libraries can sometimes be a hard sale. It cost money to have people go through and change working code and it opens up the opportunity for new bugs.

Should we upgrade to jQuery 3?

Compatibility with future code. It will be much faster and cheaper to change the website in the future because 3.0 is more standards compliant and is easier to debug. Why is it better?

  • JQuery 3 aggressively implements newer web standards. This means jQuery code and non-jQuery code(plain JavaScript/DOM/Browser APIs) will be more easily interchangeable. Specifically, on AJAX URLs, DOM manipulation, and Promises.
  • Animation performance will greatly improve.
  • Method signature and return values changes are sensible and help write more concise code and are easier to debug. Specifically, the $.post/$.get methods now accept options, and that DOM ctor now returns an empty array instead of a null value.
  • Real Promise support means interoperability with Promise debugging now and Async Functions in the future.

Upgrading to 2/3 will lose pre-IE9 support, but practically no one uses IE8 and older (.1% of all usage):

(Note, for you, the Blog Reader, this may be different, depending on what projects you work on).

Most likely areas for changes:

  • AJAX method changes. Drop success/error/complete for then, catch, done, fail, and always.
  • $.removeAttr use when it should be $.prop(attr, false)
  • Use of the $.param method

Installing Maven (2016)

It seems that the Maven installation instructions around the web are convoluted or out of date. (I kept getting:  “Error: ACould not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher”) Here’s how I did it with v.3.3.9 on Windows 10, I see no reason why this wouldn’t be the same on Linux or  Mac with the relevant parts changed.

1. Download the (the full zip is missing stuff.)(If you’re on linux, use the gunzip file.)

2. Set the JAVA_HOME environmental variable. The dependency on JavaSDK must explicitly be referred to with the environmental variable JAVA_HOME = C:\Program Files\Java\jdk1.x.x_xx (in my case: C:\Program Files\Java\jdk1.8.0_91) or wherever you keep your Java SDK.

3. Unzip Maven, I put my portable executables in C:\tools\ so mine was extracted to C:\tools\maven.

4. Add Maven bin to PATH, in my case C:\tools\maven\bin
(see below this article, if you need instructions on that).

5. Test it out in the command prompt, by typing: mvn -v

And your done!

Errors to Avoid:
1) Older versions required setting M2_HOME, M3_HOME, and/or MAVEN_OPTS. The should be blank and not exist. 2) Tutorials often tell you to install the full file, just download the bin. If you need the rest of Maven, you’ll know you need it and you probably won’t be reading this tutorial.

2) “Error: ACould not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher” is popping up because you’re missing packages, if you install the “full” version, it’s missing this. If you install the -bin version suggested above, it is not missing.

3) Setting/Editing Environmental Variables
In Windows, it’s easiest to access from the start menu. Open Start and search for (or just start typing) Environmental Variables… and you’ll see suggesstions from Windows to the right place by the time you get to “Envi.” Click one that says something like, “Edit the system environmental variables” or “Edit the environmental variables for your account.”

I like to use the account level, not the system level variables. To change a variable, you click on it and select edit. This will give you a prompt with the variable name and the value. For path, pre-Windows 10 mid-2015, you needed to manually add in the path by editing the PATH variable. c:\existing\paths;c:\existing\paths;c:\path\to\maven\which\you\added

Make a copy and save the existing path if you’re doing it this way. You don’t need to accidentally ruin your PATH variable. No it’s not the worst thing to recover from, but just save a copy first. Make gramps over here happy.

Notice the semicolon before your new one.

Windows 10 makes it even easier. When you edit PATH you get a cool interface that makes it easy to do and hard to mess up.

Command line? Don’t, but if you insist: set PATH=%PATH%;C:\path\to\maven\bin (this adds it to the beginning, this is like doing “path = new + path;” in other languages).
Linux/Bash? PATH=/data/to/maven/bin:$PATH

Gulp/Babel-loader and Webpack in Visual Studio Code

Sample VS Code config files for gulp-babel-loader.


These two lines aren’t needed in node gulp apps, but they make errors (cannot resolve module ‘myModule’…) in VS Code.





Using ES6/ES2015 in a Node.JS and Express

These are some very minimal changes to the standard express.js generated app.js file. It looks nice, “=>” syntax is getting easier to read the more I use and get used to it. Note: I took out a lot of unrelated code to isolate the topic of the blog. This example is for getting a development, learning environment ready to use Babel.js with Express on the back and front ends.

How’d I do it?

Using Babel’s “babel-node” cli tool, its compiling in real time in the development env. For production, do not use babel-node, you’ll want to compile with Babel.js then run with node. Just use “npm install -g babel-cli” and babel-node is already there and built in.

I also included eslint for good measure. Make sure to “npm install –save-dev babel-eslint” and set the parser to “babel-eslint.”

What else do you suggest that can I do to the app.js to take advantage ES6 features, without straying too far from the default?

NPM as an automated build system.

I hate having to set up complicated environments. I like JavaScript/Front End Development environments to be:

  1. Easy to understand and follow along for everyone on the team.
  2. Quick to get running and make changes.
  3. Free of having to learn new domain specific or pseudo languages for simple building.

Other platforms, Java or .NET, benefit from IDEs because they follow a predefined path and have a set of best practices defined into the language. The ugliness of JavaScript is why it’s powerful. But it can also lead to a lot of unnecessary reinventing the wheel.

Using NPM to use simpleton and replaceable tools keeps my projects fitting those three points above.

NPM is amazing and powerful. I’ve built three major projects now without Grunt or Gulp, using only NPM and locally installed modules.

The run command lets you run a locally installed module from the command line.

This runs “mocha test.js”

Scripts can also call one another.

In this previous example, “npm run check” will execute lint and test.

You can also use other NPM modules to run and watch the app.

For instance, in the following example, I use babel to convert and bundle the files after the lint and test. Then I run nodemon, which I have executing a custom script. Nodemon is also told to ignore the public directory where babel places the bundle. (I learned the fun way that this creates an infinite loop, if you don’t ignore it!)

Now when I run “npm run auto-start” it won’t just run the lint and tests and launch the app, nodemon will also watch for changes, linting, testing and restarting each time a change is detected.

Building from NPM is incredibly powerful. When I need to change the files or directories, I can do it inside the string. If I want to change the linter, I can change the dependency, and the script for “lint’s” value. Run “npm install” to update the dependencies. Then all the existing “npm run lint” calls will call the new linter. There’s only a tiny amount of configuration and no coding, just a JSON file describing what I want to happen.

Multiple calls to the same NPM module are possible, while using a different command to have different options.

Finally, the best part about building with NPM way: All that someone on the team needs to do to include this automation or build this app on another machine is clone the files and run “npm install” to get it up and running (if they have Node installed).

When won’t automated building with NPM work? Well, sometimes I have more complex builds, where one area of code might use one set of tools and another area uses some other tools. Some operations are easier to do asynchronously, rather than through piping stdout. What I’ve found myself doing more, is using NPM for my smaller personal modules and I’m still using grunt for my large projects.

Thanks for reading, if you have any ideas, concerns, or complaints please let me know on twitter @StevenLacks or in the comments.

Chaining and other Practical Uses for Promises for JavaScript (ECMAScript6, ES2015)

Repo on Github here.

Promises are cool. The best source for Promise API basics is still the API documentation on MDN. Well here’s some news. Promises are awesome and really easy to work with. That article will teach you all about the built in methods, like “all” and “resolve”, we’re going to go over some useful techniques that are not built into the Promise object.

First, let’s do a simple promise.

What if we want to do something sequentially? Promise.all() waits for all of the promised functions, Promise.race waits for one… but a lot of times, we want to run sequences without losing the benefits of asynchronous code.

Next, let’s make it a bit more complex, with issuing the then in the then. Adding the reseting the counter and using our thenableLoop.

| 0 – Working
| 1 – Working
| 2 – Working
| 3 – Working

This outputs like so:

| 0 – Working
| 1 – Working
* 0 – Working
* 1 – Working
* 2 – Working
* 3 – Working
* 4 – Working
* 5 – Working

You can also pass callbacks as promisables…

That outputs…

| 0 – Still Working
| 1 – Still Working

Keep in mind if we passed in promisable, instead of promisable 2 it would look like this:

| 0 – Still Working
| 1 – Working

Finally, let’s look at binding arguments to the promise…

This outputs:

| 0 – Custom String
| 1 – Custom String

You can have very powerful sequences, with non-blocking IO. This is great for real world applications using ES2015/ES6. You could easily replace our timeouts in these examples with AJAX calls, queries to a datastore, complex DOM interactions, or anything else you might want to ensure is done before executing another set of instructions.

Repo on Github here.

Update: Guatom makes a good point (in the comments below), we’re all more familiar with ES2015 concepts, you can avoid using “bind” by using arrow functions, which keep the context of where the function was called.

T-Mobile Data Usage

Previously, I was on the T-Mobile 1GB plan. Towards the end of the month, I’d always hit 1GB, sometimes a day or two early. I realized that the day or two of lost productivity would be worth upgrading to 3GB… so I did… Now, a day or two before the new month, I’m getting the same warnings and I’m hitting 3GB.

Now, my usage probably has increased a bit, but I doubt by 2GB more… and I’m still on wifi most of the time.

Has anyone else had this experience?