Debugging laboratory: three bugs personally

Learning route

Prepare first, then do it; after seeing the result, remember to save it.

Every time a small step is completed, it is tested. Say what you expect to see first, and then use Play and Output to check it. Don't rush to write all the code at once.

Step by step

01·Write a reproducible description of the problem

"The gold coin is broken" is too vague. "Enter the game, touch Coin once, and Coins change from 0 to 2" can help others find the problem.

Only one reason is changed in each round of debugging. After making changes, return to the same starting point and repeat the operation to determine whether the repair is effective.

1. Recording: Operational steps, expected results, actual results.
2. Open Output and look first at only the earliest red errors associated with your script.
3. Click the source or line number of the script and position it to the code.

Step by step

02 · Object not found: first look at the path without waiting

Create Coin in Workspace, and then run the following small example of intentional errors in DebugLab. Cion is misspelled, FindFirstChild returns nil, and an error is reported when the next line accesses Color.

The fix is to change the name to Coin and explicitly check if the object exists if necessary. Adding a wait to the wrong name will not create an object.

1. Only run this deliberately incorrect code in an experimental copy of Lesson28.
2. After seeing the error, record the line number, and then correct Cion to Coin.
3. Replay Play, confirm Coin becomes green.

local coin = workspace:FindFirstChild("Cion") -- 故意拼错
coin.Color = Color3.fromRGB(80, 220, 130)

Step by step

03 · No error is reported, or the calculation may be wrong

Writing >= as > will not generate a syntax error, but will reject players who "just meet the threshold". Test it with three numbers and you'll find it easier than trying it just once.

Below is the complete test after repair. assert will stop when the condition does not hold and indicate which case failed. There are no scene dependencies here and it is suitable for independent operation.

1. Replace DebugLab, run the correct version, and see All boundary checks passed.
2. Temporarily change >= in the function to >, run it again, and observe that the test equal to the threshold fails.
3. Run it again after repair, don't just watch the red line disappear.

local function canEnter(energy)
    return energy >= 5
end
assert(canEnter(4) == false, "Below threshold")
assert(canEnter(5) == true, "Exactly at threshold")
assert(canEnter(6) == true, "Above threshold")
print("All boundary checks passed")

Step by step

04 · One operation, two responses: check the connection location

If the number increases twice each time the button is clicked, first search whether there are two scripts, or the same event is Connected twice. The render function that updates the interface should not reconnect the event every time.

If you need to repeat and close functions over a long period of time, keep the connection object and, if not, Discontract. The normal buttons are usually connected only once at the start of the script.

1. Looking back at Lesson 16, confirm that Activated:Connect is outside render.
2. Add a print to the callback and observe how many times a click is executed.
3. Do not mask duplicate connections with longer cooling; the source of duplication should be repaired.

Step by step

05 · Use breakpoints to pause at a critical step

Set a breakpoint next to the Script Editor line number and let the program stop before comparison or assignment during Play. Hover with a Watch or variable to see energy instead of guessing what it is.

Removes or disables breakpoints after debugging and runs again. Otherwise, the next test will suddenly be suspended and you will think the game is stuck.

1. Set a breakpoint on the return line of the boundary test function.
2. Runs and views the parameters in order of four, five, six.
3. Continue execution until the test is completed, then clear the breakpoint.
4. If the current version has different interfaces, look for tools such as Debugger, Breakpoints and Watch.

Step by step

06 · Keep Output and Scene clean

Meaningless print every frame will drown out the real problem; objects that are constantly Instance.new but not cleaned up will accumulate more and more. Measure and position first, then decide what to optimize.

The acceptance of this lesson is a repeatable result, not a claim of "no bugs at all". Keep a record of what you measured and what you didn’t measure so that you can continue next time.

1. Remove temporary high-frequency output and retain useful stage or failure messages.
2. Run a few more rounds and observe whether new objects with the same name are continuously added.
3. Write down three fixed problems and corresponding verification steps.

Exit questions

Answer it yourself first, and then expand on it.

Explore further

This is where we start when we need to check the data.

The text code can be copied directly. First confirm the script type, placement, and whether this code is a complete version or a small experiment; do not run multiple versions of the same script superimposed. The source of the interface reference picture has been marked. The object names in the picture may be different from those in this lesson. Please refer to the operation steps.

• Studio Debugger ↗
• Output window ↗