Handle Errors Gracefully

public Boolean enroll(Student student) {
    if (student == null) {
        System.debug('Cannot enroll a null student.');
        return false;
    }

    for (Student existing : enrolledStudents) {
        if (existing.getStudentId() == student.getStudentId()) {
            return false;
        }
    }

    if (enrolledStudents.size() >= maxSize) {
        return false;
    }

    enrolledStudents.add(student);
    return true;
}

Without this check, student.getStudentId() inside the loop would throw a NullPointerException the moment someone accidentally passes null — a crash for what should be a simple, handleable rejection. Checking student == null first turns a crash into a clean "no."

• Expected business outcomes (roster full, already enrolled, null input) — these are normal things that happen in real usage. Returning false and debugging a clear reason is enough; the caller can check the result and react.
• Genuine programming errors — like a CourseRoster created with a negative maxSize, which should never happen if the rest of the code is correct — are better suited to throwing an exception (covered in a later module), since they signal a bug rather than a normal outcome.

CourseRoster apexBasics = new CourseRoster('Apex Basics', 2);

Student alice = new Student('S001', 'Alice Nkosi', 'alice@example.com');
Student ben = new Student('S002', 'Ben Dlamini', 'ben@example.com');
Student carla = new Student('S003', 'Carla Botha', 'carla@example.com');

apexBasics.enroll(alice); // true
apexBasics.enroll(ben);   // true
apexBasics.enroll(carla); // false — roster full, handled cleanly, no crash

A real registrar's system processes hundreds of enrollment attempts, many of which fail for ordinary reasons like a full class. Graceful handling means the whole batch keeps running instead of one rejected enrollment crashing the entire process.