Common Built-In Exceptions

Student student;
System.debug(student.getName()); // NullPointerException

1. Student student; — declared but never assigned an object — its value is null.
2. System.debug(student.getName()); — calls a method on something that's null — there's no actual object there to act on.

Decimal result = 10 / 0; // MathException

1. Decimal result = 10 / 0; — invalid arithmetic — division by zero being the classic case, first seen back in Module 8's calculator project.

List<String> names = new List<String>{'Amara', 'Ben'};
System.debug(names[5]); // ListException: index out of bounds

1. List<String> names = new List<String>{'Amara', 'Ben'}; — a list with only two elements, at indexes 0 and 1.
2. System.debug(names[5]); — tries to access index 5, which doesn't exist.

try {
    Decimal result = 10 / 0;
} catch (MathException e) {
    System.debug('Specifically a math problem: ' + e.getMessage());
} catch (Exception e) {
    System.debug('Some other problem: ' + e.getMessage());
}

1. try { — the risky block.
2. Decimal result = 10 / 0; — throws a MathException.
3. } catch (MathException e) { — catching the specific exception type first lets you react precisely to the failure you actually expect.
4. System.debug('Specifically a math problem: ' + e.getMessage()); — the precise handling.
5. } catch (Exception e) { — a trailing generic catch acts as a catch-all safety net for anything else.
6. System.debug('Some other problem: ' + e.getMessage()); — the generic handling.
7. } — closes the chain.

Apex checks catch blocks top to bottom, matching the first one whose type fits — the same ordering logic as an if/else if chain from Module 6.