1.1.17 Understanding Exceptions in C#

Some Problems Appear Only While the Program Runs

A C# program can build successfully and still encounter a problem during execution.

C# represents many runtime problems using exceptions.

An exception tells you that the program reached a situation it could not continue through normally.

At this stage, the goal is to recognize and diagnose an exception.

You are not yet learning full exception-handling design.

Build Errors and Exceptions Happen at Different Stages

Build/compiler problem

The compiler cannot successfully translate the current source.

Example idea:

player1.jerseyNumber = "seven";

when jerseyNumber expects an int.

Runtime exception

The source built, the program started, and a problem occurred while a statement executed.

Example idea:

player1.team.name

when:

player1.team = null

The code is syntactically meaningful.

The runtime state makes the operation impossible.

An Exception Has a Type

C# exceptions have types that help describe what kind of runtime problem occurred.

In Module 1.1, the important example is:

NullReferenceException

Later programming modules introduce other exception types in more depth.

For now, use the exception type as diagnostic evidence.

Visual Studio Can Pause at the Failing Statement

When debugging, Visual Studio can stop near the statement where the exception occurred.

That gives you a useful investigation point.

Ask:

• Which statement was executing?
• Which object references does that statement use?
• What values do those references have?
• Which part of the statement could not be completed?

Do not immediately rewrite the whole method or class.

Use the paused state.

Read the Exception Message

An exception can provide:

• an exception type;
• a message;
• a source location;
• additional debugging information.

Read the type and message before changing code.

A message is not always a complete explanation of the underlying design problem, but it narrows the investigation.

Exceptions Depend on Runtime State

Consider:

team1.name

If team1 refers to a Team object, the member access can work.

If:

team1 = null

then the same source statement can fail at runtime.

The source text did not change.

The runtime state did.

This is why debugger observation matters.

Exceptions Are Not the Same as Incorrect Output

Suppose the program displays:

Jordan

when the requirement expected:

Casey

The program may run without throwing an exception.

That is still a behavioral error.

An exception is one kind of failure signal, not the only way software can be wrong.

Do Not "Fix" an Exception by Hiding the Statement

If a statement throws an exception, commenting it out may make the program continue.

That does not automatically solve the requirement.

The removed line may represent required behavior.

In CO-029, you will use temporary commenting as a diagnostic technique while keeping the difference between:

temporary investigation

and:

actual correction

clear.

The Current Module Focuses on Diagnosis

A useful exception workflow is:

1. Observe the exception type.
2. Read the message.
3. Identify the current source statement.
4. Inspect the runtime values used by that statement.
5. Connect the failure to the requirement or object model.
6. Make only a correction supported by that evidence.

Detailed try/catch, throwing exceptions intentionally, and exception propagation belong to later programming instruction.

The Main Idea

An exception tells you:

The program built, but the current runtime operation failed.

Treat the exception as evidence about:

• where execution failed;
• what object/value state existed;
• what assumption in the source may not have been true.

CO-029 applies that reasoning to one of the most common beginner exceptions: NullReferenceException.