Handle Edge Cases

public Employee getEmployee(String employeeId) {
    if (! employeesById.containsKey(employeeId)) {
        System.debug('No employee found with ID ' + employeeId);
        return null;
    }
    return employeesById.get(employeeId);
}

1. public Employee getEmployee(String employeeId) { — the lookup method.
2. if (! employeesById.containsKey(employeeId)) { — checks explicitly before looking up.
3. System.debug('No employee found with ID ' + employeeId); — without this check, calling getEmployee('E999') for a nonexistent ID would already return null silently (recall Module 16's "Maps" lesson) — this logs the reason clearly instead.
4. return null; — still returns null — "not found" is a normal, expected outcome.
5. } — closes the if.
6. return employeesById.get(employeeId); — the normal, found case.
7. } — closes the method.

public Boolean addEmployee(Employee emp) {
    if (emp == null) {
        System.debug('Cannot add a null employee.');
        return false;
    }
    if (employeesById.containsKey(emp.getEmployeeId())) {
        return false;
    }
    employeesById.put(emp.getEmployeeId(), emp);
    return true;
}

1. public Boolean addEmployee(Employee emp) { — the method, now with a null guard added first.
2. if (emp == null) { — checks for null before anything else touches emp.
3. System.debug('Cannot add a null employee.'); — a clear reason logged.
4. return false; — rejects cleanly. Without this guard, emp.getEmployeeId() further down would throw a NullPointerException on a null emp — exactly the failure mode from Module 13's "Common Built-In Exceptions" lesson.
5. } — closes the if.
6. if (employeesById.containsKey(emp.getEmployeeId())) { — safe now, since emp is guaranteed non-null.
7. return false; — rejects a duplicate.
8. } — closes the if.
9. employeesById.put(emp.getEmployeeId(), emp); — only reached if every check passed.
10. return true; — reports success.
11. } — closes the method.

• "Not found" (a valid lookup that simply has no match) is an expected outcome — a normal part of using the directory. Returning null with a clear debug message is enough.
• "Invalid input" (a null Employee, or one with a blank employee ID) is a programming mistake on the caller's part — still handled without crashing, but worth treating as a more serious signal that something upstream is wrong.

Both get handled gracefully here, but recognizing the difference helps decide, in later modules, when a situation is serious enough to warrant a custom exception (Module 13) instead of just a false return value.