Don't panic when an error appears

If you write code, errors will appear. Even pros produce them every day. What matters isn’t avoiding them, but “what you do when one shows up.” An error isn’t scolding you—it’s a hint saying “fix this here and it’ll work.” Just being able to see it that way makes things a lot easier.

First, know where errors appear

The places errors show up are mostly fixed.

• The browser’s Console … when JavaScript doesn’t work right, it shows up here in red text. To open it, press F12 (on Mac, ⌘ + ⌥ + I).
• VSCode’s squiggly line … a red squiggly line appears where the writing is off. Hover over it with your mouse and the reason pops up in a bubble.
• A blank or broken screen … that’s a signal too. It’s a cue that whatever you just wrote is the suspect.

Read the parts of the error that actually matter

A long, technical-looking message makes you brace yourself, but there are only two places to look.

1. The message body … “what” is the problem. Example: Uncaught SyntaxError: Unexpected token
2. The file name and line number … “where” it happened. Example: script.js:12 means around line 12.

You don’t need to decode all of it. Just going to look near the line number very often turns up the cause.

What common error messages mean

Once you know what the message itself is saying, it gets much easier to guess the cause. Let’s go over just the ones you’ll see most often.

You don’t need to memorize them all. Just building up your stock of “I’ve seen this message before” completely changes how prepared you feel the next time one appears.

Follow one real example all the way through

Reading errors sticks best after doing it once end to end. Here’s a common one, chased from start to finish.

Say the Console shows this.

Uncaught ReferenceError: changeColor is not defined
    at HTMLButtonElement.onclick (index.html:12)

Break down what it tells you.

1. ReferenceError—the signal for “that name can’t be found”
2. changeColor is not defined—the missing name is changeColor
3. index.html:12—the call is on line 12 of index.html

So: “line 12 calls changeColor, but no function by that name exists anywhere.” With that much settled, you just work through the candidates.

• A different spelling—check the definition isn’t changecolor (upper and lower case are different things)
• The load order is backwards—a script tag at the top of body gets called before the function exists. script belongs just before the closing </body>
• The JS file never arrived—check whether script.js is a 404 in the Network panel

The error name gives the kind, the message gives the subject, the line number gives the place. Every error reads in those same three steps.

Make VSCode’s squiggles work for you

Picking up what the editor tells you, before you even run it in the browser, cuts down on backtracking.

• A red squiggle—a way of writing that won’t work as is. Hover for the reason
• A yellow squiggle—it works, but isn’t recommended
• The bell at the bottom left—the count of warnings in the file. If there’s a number, click it for the list

Most unclosed brackets and misspellings can be caught here, while you’re still typing. Simply running your eye over the squiggles before you reload the browser saves you half your errors.

Calmly close in on the cause from both sides

When you don’t know what’s wrong, narrow the range down.

• Suspect what you just changed … if it was working until just before, the culprit is usually the last change.
• Comment out a part to remove it (⌘ / Ctrl + /) … if removing it fixes things, you know that’s the cause.
• Check bit by bit … rather than writing everything and then running it, writing a little and checking makes it easier to find the cause.

When there’s no error but it still doesn’t work

The Console is quiet, yet nothing does what you want—this happens a lot too. Here are the classic “quiet failures” that never become errors.

• You haven’t saved the file … you rewrote it but forgot to save, and the browser is looking at the old file
• You were editing a different file … there were two files with similar names, and you were fixing the one that isn’t displayed
• A typo in the HTML … even if you get a tag name or attribute wrong, HTML doesn’t throw an error—it silently ignores it
• A typo in the CSS … even if you get a property name wrong, that one line just doesn’t take effect and no error appears

“Did you save? Did you reload? Are you looking at the right file?”—checking these three first is the shortcut.

If you still can’t figure it out, “search”

Here’s the single most useful trick. Copy the error text as-is and search for it. Someone else got stuck in the same place, and their answer is usually already out there.

• Copy and paste the message itself as-is and search for it
• Delete one-off words like your own name or file name before searching—it’s easier to get hits
• Showing an AI “I got this error” together with the error text and the suspicious code is fast too

There’s a knack to reading the results, too.

• Read the top two or three, even when one looks definitive—old answers linger near the top. Check the dates and prefer the recent ones
• If MDN comes up, read that—it’s the source closest to what browsers actually do, and more reliable than a roundabout tutorial
• Don’t close the English pages—answers in programming are found faster in English, and your browser’s translation is good enough

The order to try things in

Working down this list solves nearly every stumble.

1. Check you saved (⌘ / Ctrl + S)
2. Reload (if nothing changes, ⌘ / Ctrl + ⇧ + R to ignore the cache)
3. Open the Console and look for red text
4. If there is any, read the three parts: error name, message, line number
5. Look around that line and check spelling, matching brackets, and stray characters
6. If you’re still lost, undo your last change (if it works when reverted, that’s your culprit)
7. Search the error text as is, or show an AI the error and the code

Summary

1. An error isn’t a failure—it’s a notice of “where to fix”
2. Look at the message body and the line number and you can pin down the location
3. Learn the meaning of messages you see often, like is not defined and Unexpected token
4. For a malfunction with no error, first suspect these three: save, reload, and which file you’re looking at
5. Read it in three steps: the name for the kind, the message for the subject, the line number for the place
6. Glancing at VSCode’s squiggles before the browser saves you half your errors
7. If you can’t figure it out, just search the error text as-is or ask an AI

Once you make friends with errors, you can move forward on your own. Whenever you’re stuck, come back and skim this page again.