Exceptions and Defensive Programming

Starter: think before typing

Before running this robustness example, find the line where the main idea becomes active. Write a prediction: what must already be true for that line to work, and what should be different after it runs? The checked run ends with `Enter a whole number.`; predict how the focus line helps produce that evidence.

Learning Objectives

• Distinguish expected validation failures from exceptional failures.
• Use try/catch with a clear recovery plan.
• Throw exceptions when an object cannot be valid.
• Avoid swallowing errors silently.

Learning Outcomes

• By the end of the lesson, you can distinguish expected validation failures from exceptional failures.
• By the end of the lesson, you can use try/catch with a clear recovery plan.
• By the end of the lesson, you can throw exceptions when an object cannot be valid.
• By the end of the lesson, you can avoid swallowing errors silently.

Why this idea exists

Exceptions exist because error handling tangled into normal logic can make programs unreadable and unreliable. Languages introduced structured exception mechanisms to separate unusual failure paths from ordinary flow.

Defensive programming recognises that the world outside a method is not always well behaved: input can be wrong, files can disappear, network calls can fail and objects can be constructed incorrectly.

At degree level, the key question is recovery. Catching an exception is only useful if the program can respond sensibly; otherwise it should fail clearly, preserve evidence and avoid corrupting state.

Deep dive

Lesson visual

Type this and run it

Create ExceptionsAndDefensiveProgrammingDemo.java, type the program, and run it before changing anything. This section is about reproducing the checked baseline.

public class ExceptionsAndDefensiveProgrammingDemo {
  public static void main(String[] args) {
    String input = "forty";
    try {
      int value = Integer.parseInt(input);
      System.out.println(value);
    } catch (NumberFormatException ex) {
      System.out.println("Enter a whole number.");
    }
  }
}

Build and run it with:

javac ExceptionsAndDefensiveProgrammingDemo.java && java ExceptionsAndDefensiveProgrammingDemo

Expected baseline: Enter a whole number.

Line-by-line explanation

Read the code as a sequence of responsibilities. The focus line for this lesson is String input = "forty";; the surrounding lines prepare it, use its result or make the behaviour observable.

Worked example

Trace the program

Common misconception

A common mistake in exceptions and defensive programming is treating the example as a finished answer. For robustness, the important question is narrower: which operation carries the idea, what does it make possible, and what would break if you changed it carelessly?

Quick checks

How to study this lesson

For Exceptions and Defensive Programming, predict how robustness changes the run before you press Run.

Use the first portfolio task as your main edit: Add validation to a constructor.

Use the second task as your variation: Handle invalid numeric input.

Finish with evidence, not a diary entry: Write one test for an exception path.

Portfolio Practice

1. Add validation to a constructor.
2. Handle invalid numeric input.
3. Write one test for an exception path.

Final self-check

Study route

Practise robustness by predicting the Java example, typing it, running it in the browser, tracing the result and saving portfolio evidence.

Next, move into Recursion, Sorting and Searching and carry forward one improvement from this lesson into the next program.