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);
}

Without this check, calling getEmployee('E999') for a nonexistent ID would already return null silently (recall Module 16's "Maps" lesson) — but adding the explicit check here means the reason is logged clearly, rather than a caller discovering a mysterious null further down the line with no explanation.

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;
}

Without this guard, emp.getEmployeeId() on a null emp would throw a NullPointerException — exactly the failure mode from Module 13's "Common Built-In Exceptions" lesson. Checking emp == null first turns a crash into a clean, logged rejection.

• "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.