Custom Exceptions

public class RosterFullException extends Exception {}

Any class that extends Exception becomes throwable — this one-liner is often all a custom exception needs. Apex's built-in Exception class already provides getMessage(), getStackTraceString(), and everything else needed to work like any other exception.

public class RosterFullException extends Exception {}

public void enroll(Student student) {
    if (enrolledStudents.size() >= maxSize) {
        throw new RosterFullException('Cannot enroll ' + student.getName() + ' — roster is full.');
    }
    enrolledStudents.add(student);
}

try {
    courseRoster.enroll(newStudent);
} catch (RosterFullException e) {
    System.debug(e.getMessage());
}

throw raises the exception immediately, stopping normal execution and jumping straight to a matching catch — the same way a built-in exception like MathException would, but now naming a business-specific failure instead of a generic language-level one.

Module 12's enroll() method returned false on failure instead of throwing — a perfectly valid choice for an expected outcome. A custom exception fits better when a failure is exceptional enough that it should interrupt the normal flow and be handled distinctly. Compare:

catch (Exception e) {
    // Could be ANY problem — a typo, a null field, a real business rule.
}

catch (RosterFullException e) {
    // Unambiguous: this specific business rule was violated.
}

A named exception type turns "something went wrong" into "specifically, the roster was full" — both for a human reading the catch block and for code that wants to react differently to different named failures.