Section 7.2 Standard Library Exceptions

Subsection 7.2.1 Preventing a Bill-Splitting Crash

• Option 1 (Manual Check): Before dividing, do if (numberOfPeople == 0) { /* handle error */ }. This way, you ensure no crash occurs.
  🔗
• Option 2 (Exceptions): If you forget the check, Java automatically throws ArithmeticException. But it’s an unchecked exception, so the compiler doesn’t force you to handle it.
  🔗

Subsection 7.2.2 Categories of Java Exceptions

• Category: Error
  🔗
• Purpose: Critical failures that affect the entire system. Not meant to be handled.
  🔗
• Examples: OutOfMemoryError, StackOverflowError
  🔗
• Do You Handle It? ❌ No, usually unfixable.
  🔗

• Category: Checked Exception
  🔗
• Purpose: Recoverable failures that Java forces you to either handle (try/catch) or declare (throws).
  🔗
• Examples: IOException, ClassNotFoundException
  🔗
• Do You Handle It? ⚠️ Required: Either (try/catch) OR (throws).
  🔗

• Category: Unchecked Exception
  🔗
• Purpose: Programmer mistakes that cause a crash at runtime.
  🔗
• Examples: ArithmeticException, NullPointerException
  🔗
• Do You Handle It? 🔶 You can handle them, but Java doesn’t force you to.
  🔗

• Errors like OutOfMemoryError indicate system-level failures. You almost never handle them directly—if your program runs out of memory, there’s often little you can do.

  🔗
  🔗
• Exceptions represent problems you can handle in code. They come in two types:

  • Checked Exceptions: The compiler forces you to either catch them or declare them with throws. Example: IOException.
    🔗
  • Unchecked Exceptions: The compiler does not require explicit handling. Example: ArithmeticException, NullPointerException.
    🔗

  🔗
  🔗

Subsection 7.2.3 Which Should the Compiler Force Us to Handle?

A) Force you to handle or declare IOException before running

🔗

B) Assume you’ll remember to check manually

🔗

🔗

A) Force the programmer to write try/catch around every division

🔗

B) Assume the programmer will fix or avoid dividing by zero

🔗

🔗

Subsection 7.2.4 Checked and Unchecked in Practice

public class ExceptionDemoSkeleton {

    // Checked exception example
    public static void readData() throws ??? {
        // What checked exception might we throw here?
        // e.g., throw new ???("Unable to read data...");
    }

    // Unchecked exception example
    public static int safeDivide(int x, int y) {
        // What if y == 0?
        // Return x / y or do a manual check?
        return ???;
    }
}

Subsection 7.2.5 Why throw new Exception(...) Is Too Generic

public static void setAge(int age) throws Exception {
    if (age < 0) {
        throw new Exception("Something went wrong!");
    }
    // ... proceed with setting age
}

public static void setAge(int age) {
    if (age < 0) {
        // IllegalArgumentException is unchecked, but communicates exactly what happened
        throw new IllegalArgumentException("Age cannot be negative.");
    }
    // ... proceed with setting age
}

Subsection 7.2.6 How to Handle Exceptions in Your Own Code

• The compiler won’t let you ignore it
  🔗
• You must use try/catch or declare throws
  🔗
• These usually mean something external went wrong (like a missing file)
  🔗

• These usually mean a bug in your code
  🔗
• Instead of catching them, fix the mistake that caused them
  🔗
• Common examples: dividing by zero, using null values
  🔗

• Never use throw new Exception(...)—it’s too vague
  🔗
• Choose specific exception types that clearly describe what went wrong
  🔗
• For dangerous operations (like division), check for invalid values first
  🔗
• When reading files or using networks, always handle checked exceptions
  🔗

• Handle external failures (files, networks) using try/catch or throws
  🔗
• Avoid generic Exception—use a specific type like IllegalArgumentException
  🔗
• For invalid input, check manually before proceeding (e.g., don’t divide by zero)
  🔗
• If an error is a programmer mistake (like NullPointerException), fix the bug instead of catching it
  🔗