Theory
Tuesday, 11:40 am: BookBridge dies
The return desk is busy. A member hands over a book, the librarian types the number of days kept, and hits Enter with a slip of the finger: "12x".
Integer.parseInt("12x") cannot make a number from that. The program prints a red stack trace and exits. Queue stuck, unsaved records gone, and the librarian now distrusts your software.
Bad input, full crash. Java's mechanism for surviving such moments, instead of dying of them, is the exception.
Theory
The incident report
In a well-run library, a problem at the desk does not shut the building. The assistant writes an incident report (what happened, where) and passes it upward until someone authorised handles it. Only if NOBODY takes it does the building actually close.
A Java exception is that report: an object describing the problem, thrown up through the calling methods until some handler catches it. Unhandled at the top: program closed, stack trace printed.
Theory
The family tree of trouble
Every throwable thing descends from class Throwable, which splits in 2:
- Error: serious JVM-level failures (OutOfMemoryError, StackOverflowError). Programs do not try to handle these.
- Exception: problems a program CAN handle, the branch this unit lives in.
Inside Exception sits one special subtree, RuntimeException, and that split (runtime vs the rest) creates the distinction exams ask about most: unchecked vs checked.
At a glance
Checked vs unchecked exceptions
| Aspect | Checked | Unchecked (RuntimeException) |
|---|---|---|
| Compiler's demand | Catch it or declare it with throws, or no compile | No demand; strikes at run time |
| Typical cause | Outside world: files, network, devices | Logic bugs: null, bad index, bad number |
| Examples | IOException, SQLException | NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException, NumberFormatException |
| BookBridge case | Reading the catalog file | parseInt("12x"), b.title when b is null |
Quiz
Which of these is an UNCHECKED exception?
- IOException
- NullPointerException
- SQLException
- Any exception the programmer defines by extending Exception
Show the answer
NullPointerException
NullPointerException extends RuntimeException, the unchecked subtree: the compiler never forces you to handle it, it simply erupts when your logic slips. IOException and SQLException are the 2 textbook checked examples; the compiler refuses to build code that ignores them. Option D is the subtle trap: extending Exception (not RuntimeException) makes your exception CHECKED, which is exactly what BookBridge wants below.
Theory
When Java has no word for your problem
Java ships no OverdueException: "book kept beyond 14 days" is a library rule, not a Java rule. When the built-in vocabulary has no word for a domain problem, you define one:
class OverdueException extends Exception {
OverdueException(String message) {
super(message);
}
}
Extend Exception, pass the message up to the parent with super(message) (the this/super lesson at work), and callers later read it via getMessage().
Think first
Design decision: which parent?
You could extend RuntimeException instead, making OverdueException unchecked. Before tapping: which parent should a rule like overdue-return extend, and what does the choice change?
Show the answer
Extend Exception (checked). The choice decides what the compiler enforces: checked means every method that can raise an overdue case is FORCED to catch it or declare it, so no future teammate can silently ignore library policy. RuntimeException is for programming bugs you fix in code, not conditions you expect and must handle. Rule of thumb: expected business situations, checked; programmer mistakes, unchecked.
Watch out
Two lines students mix up
Exception vs Error: writing "OutOfMemoryError is an exception we should catch" loses marks twice; it is an Error, and programs are not meant to handle Errors at all.
Compile time vs run time: checked exceptions are CHECKED at compile time, but they still OCCUR at run time. The compiler verifies you have written handling; it cannot prevent the file from being missing on Tuesday.
Theory
The report is written; who files it?
You now have the whole taxonomy: Errors you leave alone, unchecked exceptions you prevent by fixing logic, checked exceptions and your own OverdueException you must formally handle. What is missing is the grammar of handling itself: how a method throws the report, how a caller catches it, and what always runs regardless. That grammar (throw, throws, try, catch, finally) is the next lesson, and it turns Tuesday's crash into a polite red message at the desk.
Summary
Key takeaways
- An exception is an object describing a runtime problem, passed up the call chain until caught; uncaught, the program dies with a stack trace.
- Throwable splits into Error (JVM-level, do not handle) and Exception (handle these).
- Checked exceptions (IOException) must be caught or declared at compile time; unchecked (RuntimeException family) strike at run time.
- NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException, NumberFormatException: the unchecked regulars.
- User-defined: class OverdueException extends Exception, constructor calling super(message).
- Extending Exception makes it checked, forcing every caller to respect the rule.
- Memory hook: an exception is an incident report, not a fire alarm.