Diagnostics

Compilation and execution answer different questions

A compiler diagnostic explains a problem found while translating source into an executable program. A runtime exception happens after a program has compiled and begun executing. A valid run with an unexpected number is another category: the program may be legal but implement the wrong rule. Keeping these categories separate prevents a debugging session from becoming a collection of unrelated edits made without knowing which stage actually failed.

The unchanged example declares a decimal variable named total and then passes that name to WriteLine. The compiler resolves the identifier to its declaration and checks that the call is legal. The source contains no intentional error. Its purpose is to provide a known-good baseline that you can break in one controlled way, observe through Check, and repair. A short reproducible baseline makes the connection between an edit and its diagnostic much clearer than a large file containing several simultaneous mistakes.

Start with the valid baseline, then misspell one name

The declaration stores 37m in total. The following WriteLine reads that value and prints 37. Run therefore has a real value to print, and no compiler recovery has to guess what the author meant. If you change only the call to Console.WriteLine(totla), the name totla has no declaration in scope. Check reports the unresolved identifier, typically with diagnostic CS0103, a source file, and a location pointing to the problematic use.

The location is a starting point for investigation, not a guarantee that every underlying cause lives on precisely that character. Check spelling, scope, and the relevant declaration. In this controlled example, restoring total is the correct fix because the declaration already expresses the intended value. Run must not produce a guessed thirty-seven for the misspelled program. Distinguish any earlier successful output still visible in the interface from a new execution of the edited source; a stale result does not prove the current source compiles.

var total = 37m;
Console.WriteLine(total);

Repair the cause instead of silencing the message

Adding a new variable named totla might remove the unresolved-name diagnostic while preserving an accidental misspelling and splitting one intended concept into two names. Changing a type, adding a cast, or deleting a failing statement can similarly make a diagnostic disappear without satisfying the requirement. Read the diagnostic text alongside the source and make the smallest change justified by the intended behavior. After the fix, check again because one syntax error can cause several follow-on messages that were not independent defects.

Compare a compilation failure with a valid wrong answer

First reproduce the single misspelling and note the diagnostic identifier, file, and line. Restore total and confirm that Check succeeds and Run prints thirty-seven. Hint: change one character group at a time and save the observation before making another edit. Then move the declaration into a smaller block while leaving the use outside it. Explain why a correctly spelled name can still be unavailable when its declaration is outside the use's scope.

Next keep the original spelling but change the literal to 38m. The program should compile and print thirty-eight, even if a requirement still expects thirty-seven. Hint: a compiler proves language rules, not every business expectation. Write down the three outcomes separately: compilation failure, successful wrong result, and successful expected result. This distinction also helps you decide when a debugger, a smaller test case, or a compiler-location jump will provide the most useful next observation.

Capture enough evidence to reproduce a failure

A useful issue report includes the current source, prepared input if any, the operation used, the diagnostic or exception text, and the expected behavior. State whether the problem occurred during Check or after execution began. For this lesson, you should be able to restore the two-line baseline without adding another declaration. That demonstrates you understand both identifier resolution and the difference between a compiler message and a legal program's numerical output.

• The unchanged sample compiles and prints 37.
• The misspelling introduces an undeclared identifier, not a guessed value.
• A successful Check does not prove the business answer is correct.
• Verify the current source instead of relying on earlier output.