Defensive Programming
By the end of this lesson, you'll be able to:
- Write code that anticipates and gracefully handles unexpected input
- Distinguish defensive checks from excessive, unnecessary validation
- Apply this course's established guard-clause habits as a deliberate, named strategy
Prerequisites: "Common Runtime Exceptions and What They Really Mean"
A pattern this course has used all along
if (student == null) {
return false;
}if (! employeesById.containsKey(emp.getEmployeeId())) {
return false;
}if (stock.Quantity_On_Hand__c < quantityShipped) {
throw new InventoryException(...);
}Module 12's null guards, Module 17's containsKey checks, Module 23's stock-level validation — every one of these is defensive programming: anticipating a specific way the code could fail, and handling it deliberately, rather than letting it produce exactly the NullPointerException or DmlException this module just spent three lessons learning to read.
Defensive checks vs excessive validation
// Excessive: checking something that genuinely cannot happen here
public Integer square(Integer number) {
if (number == null) {
return 0; // Integer parameters can be null, but is this check earning its keep here?
}
return number * number;
}Defensive programming isn't "check absolutely everything" — Module 17's "Handle Edge Cases" lesson distinguished a genuine data problem from paranoid, unnecessary validation. The judgment call is: does this specific input realistically arrive null, empty, or out of range in real usage? If genuinely not, an extra check adds noise without real protection — the same "boundaries, not everywhere" instinct from Module 28's security checks.
The mindset this whole module has been building toward
Every lesson in this module — reading logs efficiently, using checkpoints, recognizing exception messages instantly — exists because defensive programming, no matter how careful, can never eliminate every possible bug. The two skills work together: write defensively where it genuinely matters (Module 12 onward), and when something still breaks anyway, debug it efficiently rather than staring at a wall of log text (this module).
Exercise
As a comment, decide whether this method needs a defensive null check on its parameter, and explain your reasoning.
Show hint
Think about whether records is realistically ever null when this method is actually called.
Defensive Programming Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
This closing lesson names a habit this course has been building since Module 12: defensive programming — writing code that anticipates the exact failure modes covered in this module, before they ever produce a debug log to read.