Debugging the code

What this lesson covers

This lesson runs the turn-based game engine for the first time and works through the bugs that appear. The first is a null pointer exception: the win check compares each line against its first character, which is null for empty cells. Flipping the equals call and treating a line as complete only when its first character is not null fixes the crash, but the video points out that the code is now correct and harder to read than before, a situation it says is common in production systems. On the next run, the game ends immediately with no winner. Using debug points at each return statement, the video finds that a completely blank diagonal was being marked complete, because the completeness flag was set inside a loop that skipped null cells. After fixing that, printing the board after every move and adding a toString method, another bug appears: a finished column is not detected because the loop did not break once a column was complete. With that fixed, the engine is tested on a column, a row, the main diagonal and the reverse diagonal. The lesson ends on a broader point. Getting a simple game working took more than an hour, which is normal even for experienced engineers. Correctness matters, but an engineer's job is to make sure a system keeps working as changes arrive, not just that it works once. This leads into the design principles covered next.

• Comparing against a null first character caused null pointer exceptions in the win check
• A completeness flag set inside a loop that skips nulls marked blank diagonals as wins
• Debug points at each return statement helped locate the faulty conditions
• Patching bugs made the code correct but less readable
• Engineering means keeping a system working as it changes, not only making it work once