10.1 The Java Exception Hierarchy: Checked vs. Unchecked Exceptions and Errors

Oracle Java SE 17 Developer Certified Professional 1Z0-829

Track your progress as you read

Finished sections get a check mark.

1 Introduction: The 1Z0-829 Exam

About the Java SE 17 Developer (1Z0-829) Exam

2 Chapter 1: Java Fundamentals & Language Basics

1.1 Primitive Types, Literals, Wrapper Classes, and Type Promotion/Casting 1.2 Local Variable Type Inference (`var`) Rules and Scoping 1.3 Operators, Precedence, Evaluation Order, and Short-Circuit Evaluation 1.4 Text Blocks, String Immutability, and StringBuilder APIs

3 Chapter 2: Program Flow & Decision Constructs

2.1 Conditional Branching with if/else and the Ternary Operator 2.2 Switch Statements and Switch Expressions 2.3 Iteration Constructs, Loop Control, and Branching Labels

4 Chapter 3: Object-Oriented Design & Class Mechanics

3.1 Class Declarations, Field/Method Signatures, and Access Modifiers 3.2 Constructors, Overloading, Initialization Order, and Garbage Collection 3.3 Inheritance, Method Overriding, Polymorphism, and `super`/`this` 3.4 Abstract Classes, Static Members, and Object Methods (`equals`, `hashCode`, `toString`)

5 Chapter 4: Advanced OOP: Interfaces, Records & Sealed Types

4.1 Interface Architecture: Default, Static, and Private Methods 4.2 Enumerations: Constants, Constructors, Methods, and Custom Bodies 4.3 Records: Canonical/Compact Constructors, Components, and Immutability 4.4 Sealed Classes and Interfaces: `permits`, Hierarchy Constraints, and Modifiers

6 Chapter 5: Pattern Matching & Nested Types

5.1 Pattern Matching for `instanceof` and Flow Scoping Mechanics 5.2 Nested Types: Member Inner, Static Nested, Local, and Anonymous Classes 5.3 Defensive Programming, Immutability Patterns, and Validation

7 Chapter 6: Generics, Collections & Arrays

6.1 Generic Classes, Interfaces, Methods, and Type Erasure 6.2 Bounded Type Parameters and Wildcards (PECS Rule) 6.3 Collections Framework: List, Set, Queue, and Deque APIs 6.4 The Map Interface, Sorting, Comparable, and Comparator 6.5 Arrays: Declaration, Initialization, Multidimensional Arrays, and the Arrays Utility Class

8 Chapter 7: Functional Programming & Lambda Expressions

7.1 Functional Interfaces and Lambda Syntax Rules 7.2 Standard Functional Interfaces in `java.util.function` 7.3 Method References: Static, Bound, Unbound, and Constructor References

9 Chapter 8: The Stream API

8.1 Stream Lifecycle: Creation, Pipeline Architecture, and Lazy Evaluation 8.2 Intermediate Stream Operations: Filtering, Mapping, Sorting, and Slicing 8.3 Terminal Stream Operations: Reduction, Matching, Finding, and Collecting 8.4 Primitive Streams (`IntStream`, `LongStream`, `DoubleStream`) and Numeric Statistics

10 Chapter 9: Advanced Streams & Collectors

9.1 The Optional Class: Safe Null Handling, Transformation, and Chaining 9.2 The Collectors API: Downstream Reductions, Grouping, and Partitioning 9.3 Parallel Streams: Fork/Join Pool, Spliterators, and Concurrency Pitfalls

11 Chapter 10: Exception Handling

10.1 The Java Exception Hierarchy: Checked vs. Unchecked Exceptions and Errors 10.2 Exception Constructs: `try-catch-finally`, Multi-Catch, and Rethrowing 10.3 Try-With-Resources, `AutoCloseable`, Suppressed Exceptions, and Custom Exceptions

12 Chapter 11: Date/Time API & Localization

11.1 Date and Time Core Types: `LocalDate`, `LocalTime`, `LocalDateTime` 11.2 Timestamps, Intervals, and Durations: `Instant`, `Period`, and `Duration` 11.3 Time Zones, Daylight Saving Time (DST) Offsets, and `ZonedDateTime` 11.4 Internationalization and Localization: `Locale`, `ResourceBundle`, and Formatters 11.5 Formatting and Parsing Messages, Numbers, Percentages, and Localized Dates

13 Chapter 12: Java Platform Module System (JPMS)

12.1 Module Architecture, `module-info.java`, and Module Paths 12.2 Module Directives: `requires`, `requires transitive`, `exports`, and Qualified Exports 12.3 Reflection, Deep Encapsulation, `opens`, and Open Modules 12.4 Services in JPMS (`uses`, `provides...with`), Migration Paths, and Tooling (`jlink`, `jdeps`) 12.5 Compiling and Packaging Code: Non-Modular JARs, Modular JARs, and Migration Strategies

14 Chapter 13: Concurrency & Multithreading

13.1 Thread Fundamentals, `Runnable`, `Callable`, and Thread Lifecycle 13.2 Memory Visibility, `volatile`, Intrinsic Locks, and Synchronization 13.3 The Concurrency Framework: `ExecutorService`, Thread Pools, and `Future` 13.4 Concurrent Collections, Atomic Variables, Explicit Locks, and `CompletableFuture`

15 Chapter 14: Java I/O and NIO.2

14.1 Classical I/O: Byte and Character Streams, Readers, Writers, and Buffering 14.2 Object Serialization, `Serializable`, `transient`, and `serialVersionUID` 14.3 NIO.2 Architecture: `Path`, `Paths`, and Basic `Files` Operations 14.4 Advanced NIO.2: Directory Walking, Streams (`Files.lines`, `walk`), and `WatchService`

16 Chapter 15: Accessing Databases with JDBC

15.1 JDBC Architecture, Drivers, `DriverManager`, and `DataSource` Connections 15.2 SQL Execution: `Statement`, `PreparedStatement`, and `CallableStatement` 15.3 `ResultSet` Navigation, Data Types, and Transaction Management (Commit, Rollback, Savepoints)

17 Chapter 16: Annotations & the Java Logging API

16.1 Standard Annotations: @Override, @FunctionalInterface, @Deprecated, @SuppressWarnings, and @SafeVarargs 16.2 Java Logging API Basics: Logger, Levels, Handlers, and Configuration

10.1 The Java Exception Hierarchy: Checked vs. Unchecked Exceptions and Errors

Key Takeaways Explain This Topic AI

java.lang.Throwable is the root superclass of all errors and exceptions in the Java platform, bifurcating into java.lang.Error and java.lang.Exception.

Errors (such as OutOfMemoryError, StackOverflowError, and AssertionError) represent fatal system conditions or JVM failures that standard application code must never attempt to catch or recover from.

Checked exceptions are subclasses of Exception (excluding RuntimeException); the compiler enforces the 'catch-or-declare' rule, requiring them to be either caught in a try-catch block or declared in a method's throws clause.

Unchecked exceptions are subclasses of RuntimeException (or Error) that represent programming bugs or invalid states (such as NullPointerException and IllegalArgumentException); they are exempt from compiler catch-or-declare enforcement.

The compiler enforces strict reachability rules on checked exceptions: attempting to catch a checked exception that cannot be thrown within the enclosed try block results in a compile-time error, whereas catching unchecked exceptions, Exception, or Throwable is always permitted.

Last updated: October 2026

10.1 The Java Exception Hierarchy: Checked vs. Unchecked Exceptions and Errors

In Java, exceptional conditions that disrupt the normal flow of program execution are represented as first-class objects. Robust exception handling requires a deep understanding of the object model rooted at java.lang.Throwable , the fundamental architectural boundary separating recoverable conditions from catastrophic system failures, and the compiler's strict reachability rules.

The Throwable Class Hierarchy

Every exception and error in Java is an instance of java.lang.Throwable or one of its direct or indirect subclasses. The hierarchy splits into two primary branches: java.lang.Throwable

• |
• +-----------------+-----------------+
• | |
• java.lang.Error java.lang.Exception
• | |
• +----------+----------+ +----------+----------+
• | | | |
• OutOfMemoryError StackOverflowError | RuntimeException
• | |
• (Checked Exceptions) +------+------+
• e.g. IOException | |
• e.g. SQLException NullPointer- Arithmetic-
• Exception Exception

java.lang.Throwable : The ultimate root of the exception hierarchy. Only instances of this class (or its subclasses) can be thrown by the Java Virtual Machine (JVM) or by the throw statement, and only these types can appear in a catch clause or throws declaration.

java.lang.Error : Represents serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions that occur within the virtual machine itself or the underlying hardware.

java.lang.Exception : Represents conditions that a reasonable application might want to catch and recover from.

java.lang.RuntimeException : A special branch of Exception . Subclasses of RuntimeException (along with Error ) are collectively termed unchecked exceptions . All other subclasses of Exception are termed checked exceptions .

The Error Category: Unrecoverable JVM Failures

Instances of java.lang.Error designate fatal infrastructure issues or system resource exhaustion. When an Error occurs, the integrity of the JVM or the operating environment is typically compromised.

Key examples to recognize:

OutOfMemoryError : Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

StackOverflowError : Thrown when a thread stack overflows, most frequently due to infinite recursion or excessively deep call stacks.

NoClassDefFoundError : Thrown when the JVM or a ClassLoader instance tries to load in the definition of a class (as part of a normal method call or creation of a new instance) and no definition of the class could be found at runtime, even though it compiled cleanly.

ExceptionInInitializerError : Signals that an unexpected exception occurred in a static initializer block or during the evaluation of a static field initializer.

AssertionError : Thrown to indicate that an assert statement has failed.

VirtualMachineError : The abstract superclass of OutOfMemoryError and StackOverflowError .

Warning

Catching Error Is an Anti-Pattern While writing catch (Error e) or catch (Throwable t) is syntactically legal, application code should never attempt to handle or suppress Error subclasses (such as OutOfMemoryError or StackOverflowError ). Attempting to continue execution after a JVM failure leaves threads in undefined, corrupted states. Let errors propagate to terminate the failing thread or process.

Checked vs. Unchecked Exceptions

The distinction between checked and unchecked exceptions is enforced entirely by the Java compiler.

The Catch-or-Declare Rule

Java enforces the catch-or-declare contract for all checked exceptions :

Catch : Enclose the code that may throw the exception in a try block with an associated catch block that handles the exception type (or a supertype).

Declare : Append a throws clause to the enclosing method or constructor signature declaring that the method may propagate the exception to its caller.

If a method contains an invocation of code that throws a checked exception without either catching it or declaring it in its throws clause, the Java compiler refuses to compile the code. import java.io.*;

• public class CatchOrDeclareDemo {
• // Approach 1: Declare via throws clause
• public void readFile(String path) throws IOException {
• FileReader reader = new FileReader(path); // FileReader throws FileNotFoundException (checked)
• reader.read(); // read() throws IOException (checked)
• reader.close();
• }

• // Approach 2: Catch within try-catch block
• public void safeReadFile(String path) {
• try {
• FileReader reader = new FileReader(path);
• reader.read();
• reader.close();
• } catch (IOException e) {
• System.err.println("Failed to read file: " + e.getMessage());
• }
• }
• }
• Unchecked Exceptions ( RuntimeException )

Unchecked exceptions are subclasses of java.lang.RuntimeException . They represent flaws in program logic, illegal arguments, or violated object states that can theoretically occur anywhere in an application.

Because runtime errors can happen in virtually any statement (such as dereferencing a reference or dividing numbers), forcing developers to declare them everywhere would clutter code with boilerplate. Therefore, unchecked exceptions are exempt from the catch-or-declare rule.

Dimension Checked Exceptions Unchecked Exceptions ( RuntimeException ) System Errors ( Error )

Superclass Subclasses of Exception outside the RuntimeException branch Subclasses of java.lang.RuntimeException Subclasses of java.lang.Error

Catch-or-Declare Rule Mandatory : Compiler forces try-catch or throws Optional : Compiler does not require catch or declare Optional : Must not be caught by normal logic

Primary Root Cause External conditions (missing files, network dropped, SQL errors) Programming bugs, invalid input, state contract violations JVM resource exhaustion, linkage/classloading failures

Recovery Feasibility Generally recoverable with alternative workflows Recoverable through bug fixes and defensive preconditions Unrecoverable; system/JVM state is damaged

Common Built-in Exceptions for 1Z0-829

Exam questions frequently require identifying whether a specific exception is checked or unchecked, and what runtime scenario causes it to be thrown.

Unchecked Runtime Exceptions ( java.lang )

Exception Common Trigger Scenario

NullPointerException Attempting to invoke an instance method, access an instance field, or calculate the length of an array through a null reference, or unboxing a null wrapper object.

ArrayIndexOutOfBoundsException Accessing an array with an illegal index that is either negative or greater than or equal to array.length .

StringIndexOutOfBoundsException Accessing a character of a String with an index that is out of bounds (subclass of IndexOutOfBoundsException ).

ClassCastException Attempting to cast an object to a class of which it is not an instance (e.g., (String) (Object) Integer.valueOf(5) ).

IllegalArgumentException A method received an argument that is inappropriate, invalid, or violates method preconditions.

IllegalStateException A method has been invoked at an illegal or inappropriate time (the object environment or lifecycle state is not suitable for the requested operation, e.g. calling iterator.remove() before next() ).

NumberFormatException Attempting to convert a string to a numeric type when the string does not have an appropriate format (subclass of IllegalArgumentException ).

ArithmeticException Exceptional arithmetic condition, specifically integer division or modulo by zero ( 10 / 0 ).

UnsupportedOperationException Invoking a mutating method on an unmodifiable collection (e.g., List.of().add("x") ).

Warning

The Floating-Point Division by Zero Trap In Java, integer division by zero ( 10 / 0 ) throws java.lang.ArithmeticException . However, floating-point division by zero ( 10.0 / 0.0 or 10.0f / 0 ) does not throw an exception ! In compliance with IEEE 754 floating-point standards, it evaluates to Double.POSITIVE_INFINITY , Double.NEGATIVE_INFINITY , or Double.NaN (for 0.0 / 0.0 ). Watch for floating-point literals in arithmetic questions!

Checked Exceptions

Exception Package Common Trigger Scenario

IOException java.io Failed or interrupted I/O operations (broken network connection, inaccessible pipe).

FileNotFoundException java.io Attempting to open a file denoted by a specified pathname when the file does not exist (subclass of IOException ).

SQLException java.sql Database access errors, invalid SQL syntax, or lost database connections.

ClassNotFoundException java.lang An application tries to load a class through its string name (e.g., Class.forName("com.Foo") ) but no definition can be located.

InterruptedException java.lang A thread is waiting, sleeping, or occupied, and another thread interrupts it using Thread.interrupt() .

ParseException java.text An unexpected error has been reached while parsing a date or number string.

Compiler Reachability and Catch Block Validity

One of the trickiest areas on the 1Z0-829 exam involves compiler reachability checks on catch blocks. The Java compiler verifies whether a try block could ever possibly throw the checked exception listed in a catch clause:

Unreachable Checked Exception Catch Error : If a catch block catches a checked exception E E E , and the statements within the corresponding try block cannot possibly throw E E E (or any subclass of E E E ), the compiler rejects the code with an error: exception E is never thrown in body of corresponding try statement .

The Unchecked and Broad Catch Exemption : This reachability check does not apply to unchecked exceptions ( RuntimeException or any of its subclasses) or to broad catch types ( Exception and Throwable ). You can catch NullPointerException , RuntimeException , Exception , or Throwable around any arbitrary code, even an empty try block! import java.io.IOException;

• public class ReachabilityRules {
• public void testReachability() {
• try {
• System.out.println("Processing...");
• } catch (RuntimeException e) {
• // COMPILES: Unchecked exceptions are always permitted in catch blocks
• } catch (Exception e) {
• // COMPILES: Exception is broad and could represent runtime exceptions
• }

• try {
• System.out.println("Testing checked...");

// catch (IOException e) {} // COMPILE ERROR: IOException is never thrown in try block!

• } catch (Exception e) {
• // Valid
• }
• }
• }
• Java Assertions: Invariant Verification (Background)

Note

Assertions are not named in the current 1Z0-829 objectives. They appear briefly here because AssertionError belongs to the Error hierarchy and older study material still uses them; spend most of your time on the exception rules above.

Assertions, introduced via the assert keyword, enable developers to test internal assumptions and invariants during development and testing without incurring performance overhead in production.

Assertion Syntax

Java provides two forms of the assert statement:

• Simple assertion : assert booleanExpression;
• Assertion with detail expression : assert booleanExpression : detailExpression;

If assertions are enabled and booleanExpression evaluates to false , the JVM throws an AssertionError . In the two-argument form, detailExpression is evaluated and converted to a String to serve as the detail message of the AssertionError .

Controlling Assertions via the Command Line

By default, assertions are disabled at runtime. They must be explicitly activated using CLI flags:

-ea or -enableassertions : Enables assertions for all system-loaded application classes.

-da or -disableassertions : Disables assertions.

Granular control:

-ea:com.order... : Enables assertions for package com.order and all its subpackages (the trailing ... denotes subpackages).

-da:com.order.Pricing : Disables assertions for the specific class Pricing within com.order .

• More specific rules take precedence over broader rules. # Enable in all packages except com.example.cache
• java -ea -da:com.example.cache... com.example.MainApp

• Warning
• Assertion Rules and Anti-Patterns

Do not use assertions to validate arguments in public methods : Public methods must throw standard exceptions like IllegalArgumentException or NullPointerException because assertions can be disabled in production, leaving public API contracts unprotected. Use assertions for private method preconditions, postconditions, and internal invariant validation.

Never write assertions with side effects : Expressions such as assert list.remove(item); or assert count++ > 0; alter program state when -ea is active, but fail to execute when assertions are disabled, causing divergent behavior between test and production environments!