JavaScript Tutorial
JavaScript Debugging
console.log, breakpoints, and reading the error line. Fix one problem at a time, then run again.
The script is telling you something
Debugging is not guessing. The console prints values you ask for. An error names a type and a line. Your job is to compare what you expected with what actually ran, change one thing, and run again.
StudyGrid’s JavaScript editor at /javascript/try shows a page and a console.console.log lands in that console. Uncaught errors land there too, with a message.
console.log
Print the value you are unsure about, not a vague label. Log before a calculation and after. Log typeof when a method “does not exist” — the value is oftenundefined or a string.
Example
const raw = "12";
console.log("raw", raw, typeof raw);
const n = Number(raw);
console.log("n", n, typeof n);
console.log("n + 1", n + 1);
Several arguments to console.log print side by side. A short tag plus the value is easier to scan than a long sentence.
Click Try it in JavaScript under an example. That opens/javascript/try — a live page and a console.
Read the error line
TypeError, ReferenceError, and SyntaxError are the names you will see first. The message is the what. The line is the where. Open that line before you rewrite a different function.
Example
const user = null;
try {
console.log(user.name);
} catch (err) {
console.log(err.name);
console.log(err.message);
}
TypeError: Cannot read properties of null means you used a dot onnull (or undefined). Fix the value, or check it, before you add more code around it.
Common names
| Error | Typical cause |
|---|---|
SyntaxError | A missing ), quote, or brace. The file did not even start. |
ReferenceError | A name you never declared, or a typo. |
TypeError | Calling something that is not a function, or reading a field of null. |
Syntax errors stop the whole script from loading. Fix quotes and brackets first. Then run again. A red line in the editor is a gift — use it.
Breakpoints
A breakpoint pauses the program on a line so you can inspect variables. In the browser developer tools (F12 or right-click, Inspect), open the Sources (or Debugger) panel, click a line number, and reload. Step over runs the next line. Step into goes inside a call.
debugger; in the source also pauses when developer tools are open. Remove it when you are done. For StudyGrid exercises, console.log is enough; breakpoints become useful when a page has several files.
Example
function total(list) {
let sum = 0;
for (const n of list) {
console.log("adding", n);
sum += n;
}
return sum;
}
console.log("result", total([2, 3, 5]));
If the total is wrong, the log shows which round went bad. You do not need a breakpoint to find an off-by-one in a five-line loop.
One problem at a time
Change one thing. Run. Read the console. If you change five lines and the page still fails, you do not know which change mattered. Keep the last working version in the editor (or undo) so you can go back.
Example
<p id="out"></p>
<script>
const out = document.getElementById("out");
const node = document.getElementById("missing");
if (node === null) {
out.textContent = "No #missing element. Check the id.";
console.log("getElementById returned null");
} else {
out.textContent = node.textContent;
}
</script>A missing id is a frequent “nothing happens” bug. Log the lookup. If it isnull, the selector is wrong — not your later math.
What to remember
- Log the actual value and its
typeof. - Read the error name and the line before rewriting.
- Breakpoints pause a line in the browser debugger; logs are enough for small scripts.
- Fix one problem, run again, then the next.
Next: the DOM — the page as a tree of nodes your script can find and change.