Start with when the problem appears
When code does not behave as expected, ask one question first: did it start running? A syntax error usually prevents the affected code from starting. A runtime error occurs after execution begins and interrupts it. A logic bug lets the program run but produces an incorrect result. These categories do not identify the exact fix, but they help you decide where to look.
To try the examples below, you need a text editor and a browser with a JavaScript console. The examples use standard JavaScript features available in ECMAScript 2015 or later and need no libraries. Open your browser’s developer tools, find the console, and enter each example separately. Error wording and line numbers can differ between browsers.
Syntax errors: the code cannot be read as written
A syntax error means the code breaks a rule of the language’s structure. For example, enter console.log("Hello"; in the console. The closing parenthesis is missing, so JavaScript cannot parse the statement. Other common causes include unmatched braces, missing quotation marks, and punctuation in the wrong place.
Start with the location shown in the error message, but inspect the lines just before it too. A missing opening quote or closing brace may only become apparent when the parser reaches a later line. Check paired characters such as (), {}, and quotation marks. Make one small correction, then try the code again. If you entered several statements together, a syntax error can prevent any of them from running.
Runtime errors: execution starts, then stops
Runtime errors arise while the program is executing. Enter const user = null; console.log(user.name); as two statements. The declaration is valid, but trying to read a property from null causes a TypeError. Unlike the syntax example, JavaScript can understand this code; it fails when it reaches an operation it cannot perform.
Read the error message for the operation that failed, then inspect the values involved. Here, ask why user is null at the point where user.name is accessed. In a larger program, the console’s stack trace can help you follow the calls that led to the failure. A guard may be appropriate if a missing user is expected, but first find out whether null is a valid input or evidence of an earlier mistake. Code that ran before the error may already have changed program state.
Logic bugs: the program runs, but the answer is wrong
A logic bug may produce no error message at all. Suppose a function should apply a ten-percent discount: function discountedPrice(price) { return price - 10; }. Calling discountedPrice(50) returns 40, but ten percent off 50 is 45. The function subtracts a fixed amount instead of calculating a percentage. Its syntax is valid, and the subtraction runs successfully; the mistake is in the rule the code implements.
To investigate, write down the expected result for a specific input before changing anything. Compare it with the actual result and trace the calculation one step at a time. In this example, returning price * 0.9 would match the stated rule. Test more than one price afterward: an input of 100 would give the same result under both versions, so that test alone would not reveal the bug. Choose test cases that can distinguish the intended rule from plausible mistakes.
Use a repeatable debugging routine
First, reproduce the problem with a small, specific input. Next, record what you expected and what actually happened. If the code will not start, inspect its syntax. If it stops with an error, read the message and examine the values at the failing operation. If it finishes with the wrong output, compare each step of the calculation or decision with the intended behavior.
Change one thing at a time and run the same input again. Once the immediate problem is fixed, try a few nearby cases, including an empty or missing value where that is relevant. A program can contain more than one kind of bug: correcting a syntax error may expose a runtime error, and fixing that error may reveal a wrong answer. Treat each new result as information, not as a sign that the previous debugging step failed.
