The Console

Open the Console

The Console is a developer-tools panel where the browser reports JavaScript messages and lets you run code. Open DevTools with F12 on many keyboards, or Cmd+Option+I on Mac, then choose the Console tab if it is not already selected. Your bug-hunting quest uses it first because an error message often points directly to the failing file and line.

Red text usually marks an error. Read the full message, including the filename and line number, rather than only noticing that something is red. Click a source link when available to jump to the relevant code. The message is a clue about what failed, not always the whole explanation.

Test a small idea live

You can enter JavaScript directly into the Console and press Enter. This is useful for checking a value, trying a selector or testing a small expression without editing the app first. For example, inspect whether an element exists before changing the code.

const heading = document.querySelector('h1');
heading?.textContent;
2 + 3;

Optional chaining in the first check avoids another error if there is no heading. Console experiments are temporary; they do not automatically become part of your source file. Once a test helps, make the intended change in the project code.

Follow the evidence

In your planted-bug activity, reproduce the problem and inspect the Console. Note the reported file and line, then compare the message with the surrounding code. A missing property, misspelled name or failed request can each produce different evidence.

The Console can also show warnings and messages logged by your code, not only failures. Use it to verify a hypothesis, then reload or repeat the action to confirm whether the underlying bug is actually fixed. Avoid hiding an error without understanding its cause.

Keep debugging systematic

Change one thing at a time, save, and reproduce the same action. This makes it easier to tell whether a fix worked. If the error moves to a different line, the first issue may be resolved and execution has reached another problem.

For the quest, record a short comment above each fix as requested, and use the Console as evidence for your diagnosis. A useful debugging loop is observe the message, inspect the referenced code, make a focused change, and test again.

Three messages, three different investigations

On your own practice page, compare these observations:

• document.querySelector('#missing') returns null: the selector found no matching element.
• ['Ada', 'Linus', 'Grace'][3] returns undefined: the index is outside this three-item list.
• Reading aNameNeverDeclared throws a ReferenceError: that identifier does not exist in the current scope.

Null and undefined can both lead to a TypeError when you try to use a property, but their causes differ. Do not treat every red message as “the loop is broken”. Follow the named file/line and inspect the value at that point.

Use typeof to inspect a value's type. To investigate an identifier that might not exist, typeof aNameNeverDeclared can report undefined without the same reference error; a normal direct read is different. Do not rely on colours alone—the wording is evidence.

In the activity, the first selector error may prevent the later bugs from being reported at all. Correct the earliest cause, reload with the console clear, then inspect the next failure. Three bugs do not necessarily produce three messages at once.

For a safe rehearsal, predict a missing-selector result, an out-of-range result and one arithmetic expression, then run each on your local page. Never paste unknown “fix” scripts into a signed-in real website's Console. Log only harmless diagnostic values; secrets and private data do not belong in console output or tutor prompts.

Before assessment, explain the cause behind each required fix in your own one-line comment, not just “fixed bug”. Retest the visible list and confirm all expected names appear exactly once without an undefined entry.