Debugging & Error Handling

An unusual or extreme input that the code might not handle correctly. Edge cases live at the boundaries: empty strings, zero, negative numbers, very large inputs, or special characters. Many bugs hide in edge cases because developers test the 'happy path' first.

The text a program outputs when something goes wrong. Error messages usually include what failed, where it failed, and sometimes why. Sharing the exact error message, not a summary of it, is the fastest way to get useful help.

A simple framework for describing bugs: what should happen (expected) versus what does happen (actual). Stating both makes the problem unambiguous. Without the expected behavior, it's not always clear that something is wrong.

Recording what a program does as it runs: which functions were called, what data was received, what decisions were made. Logs are like a flight recorder: when something goes wrong, you read the logs to see what happened leading up to the crash.

The smallest possible example that still triggers the bug. Stripping away unrelated code makes the problem easier to spot and faster to fix. If a bug only shows up in a 10,000-line app, creating a 20-line version that reproduces it is incredibly valuable.

A bug that appears in something that used to work. It typically happens when a code change accidentally breaks an unrelated feature. Regressions are sneaky because nobody is looking for problems in parts of the app that were already working.

The exact sequence of actions someone needs to follow to trigger a bug reliably. Good repro steps mean anyone, including an AI, can see the same problem you see, which is the first step toward fixing it.

The underlying reason a bug happens, not just the symptom you see. A page might show a blank screen (symptom), but the root cause could be a typo in an API URL three files away. Fixing the root cause prevents the bug from coming back in a different form.

A list of function calls the program was in the middle of when an error occurred, shown from the most recent call back to the starting point. It's like a trail of breadcrumbs showing exactly how the code arrived at the crash.