Don't Be Afraid of the JavaScript Stack Trace

You start working on a new project right after you finish reading this post. It’s not outlandish - something not too far off from a previous project you’ve done.

After 20-or-so minutes of getting the project base ready (so that you can begin the real project), you get hit with an error. It doesn’t look too bad, but after an hour of searching on Google and making 10 changes to try to remedy the problem, you get snapped back to reality. You just spent a good chunk of time on code that won’t affect your bottom line. Even if you’re not getting paid for the project, you feel defeated.

Before diving into other avenues of fixing the issue, take a step back, clear your mind, get a drink of water, and then consider these points:

• It’s not a waste of time to LEARN - it’s a waste to mindlessly attack a problem.
• Is it worth starting over?
• Maybe you could try a different setup, like a framework, to mitigate the chances of setup errors (because that’s where the faux-reality issue is emerging). This may also make it more likely that your issues are common across other users of the framework.
• Ask for another person’s insight. An honest question is not a sign of weakness - in fact, it can increase team harmony.

Now let’s assume that you have gone through the options above. You feel that it’s best to move forward and fix this issue - what strategy can you take? We’re going to focus on one particular strategy - looking into the stack trace to determine the cause. Finding root causes are most of the battle. [Keep in mind that this short list is based on my own experience and is not comprehensive. That being said, try to have an open mind to try new tactics. 😄]

1. When you run into an issue, commit your code (at least into your local git). Even though this code may not be in a completely functional state, it is better than the mess you may eventually get to. Doing small commits along the way will help you keep track of what you’ve tried.
2. Set a timer (Pomodoro-style or just a regular timer). I suggest no more than 30 minutes. This doesn’t mean that you need a solution in that time frame, but you can use a small break to re-evaluate.
3. Have a good idea of where to look (depending on your platform).
4. Know how to pick out key words and details.
5. Understand how to look it up.

We will go into greater detail on the last three points from above.

Where to Look

Here are a few different situations and where the stack trace can show up.

• Node (backend) --> terminal console
• React / Vue / vanilla JS (frontend) --> browser console

There’s no stack trace. What do I do?

In some cases, no trace shows. Why is that? This is usually because there is a logical error (it doesn’t work the way you thought it would) and the code itself is sound. To try to find the source of the problem, you could log information to the console before and after where you think the issue is.

What to Look For

Think of a stack trace like a stack of dishes. When they are piling up and they start to fall over, you know that last couple plates are the culprit. In the same way, the most recent actions (which is likely where the problem resides) are at the top of the stack trace.

It’s also important to note that the lines you see in this trace are not all made up of errors. It is a history of where the program/script has gone up until that point, making it a great tool for pinpointing the real problem.

Error/Exception Messages

If the issue involves a package, the author may have put a good message or hint to help out. Even the language-level exceptions usually have hints. This would be the perfect place to start.

File Names

Typically the problem lies in your own source code and not other packages (at least that’s the general rule), so look for files that have your base directory. If a file is one you’ve recently made changes to, that’s a good indication to check there.

Line Numbers

You’re in luck. Not only do you get to see the file name, but the trace includes the line number and sometimes the column number. The column tends to not be as useful, but hey - thanks to whoever decided to put those in there!

Exception Type(s)

Sometimes the name of an exception thrown can give you a solid clue. Likely you won’t know exactly what it means though. Use some insight gleaned from the next section to search based on these.

If you run into this issue often, consider memorizing some of the more common exceptions for your language or framework.

How deep do I go?

Some traces are very long. You’ll likely get heavy eyelids if you have to read the whole thing as if it were a novel. So where does it shift from helpful to a waste of time?

My experience has been that you can find the clues you need in the first 5 items of the trace. If you’ve combed through it carefully and you still haven’t found anything, then, by all means, continue.

Let’s create a fake error to see some of these clues in effect. You can run this client-side or server-side:

firstFunction = () => {
  secondFunction();
}

secondFunction = () => {
  thirdFunction();
}
thirdFunction = () => {
  notDefined();
}

This produces:

What to Look Up

If a message is provided in the error, this may be the best thing to search on.

Tips for Google Search

• Use quotes to search for the exact phrase.
• Place an asterisk within those quotes to specify an unknown word or phrase.
• Use the minus sign to show that you want to eliminate results containing the word(s).
• State the phrase “how to” at the beginning if you’re looking for a tutorial (Google can be smart like that).

Tips for Stack Overflow Search

• Add tags to your query by surrounding them with square brackets: [vue] trigger an event.
• Typically you want to look for the results that have the solid green ‘answers’ box. This means that one has been accepted as the correct answer.
• Take a look at other answers besides the one marked as correct. They may be more modern or clean, or just your style.

Right click all of the search results that look promising to open them up in a new tab. For faster flow, use your platform’s shortcut key (Ctrl on Windows, Cmd on Mac) while you click the link.

Problem Solved - Or Is It?

How many times do we run into an issue, do a search, find a Stack Overflow post with the answer and then see that we’ve already upvoted it? 😆 To avoid this, we should document the issue with the solution and more importantly do at least one of two things:

1. Create a new test.
2. Write some error-handling. You could even catch the error and spit out your own error with a custom message.

if (valueIsNotCorrect) throw new Error(`D'oh, you did it again! Fix me by ...`);

To end, here’s a good laugh taken from Jordan Hall on Twitter:

window.onerror = error => {
  // redirect to SO with error as query
  window.location.href = `https://stackoverflow.com/search?q=[js]${error.message}`;
}