1Z0-830 · Domain 4 of 10

1Z0-830 Domain 4: Handling Exceptions

This section tests how Java code reports and recovers from errors: checked and unchecked exceptions, try/catch/finally flow, try-with-resources and suppressed exceptions, multi-catch rules, and writing your own exception classes.

Exam weight estimate
Not published
Official objectives estimate
1
Estimated questions estimate
~4
Suggested study time estimate
5–7 hrs

About 10 min read Reviewed October 2026

Overview

Domain 4 is one objective that packs in several mechanisms. You must handle exceptions with try, catch and finally blocks, manage resources with try-with-resources, combine handlers with multi-catch, and define custom exception classes. Underneath sits the Throwable hierarchy: Error, checked exceptions that the compiler forces you to catch or declare, and RuntimeException subclasses that it does not.

The exam tests both compile-time rules and runtime flow. Compile-time items ask whether a catch block is unreachable, whether a multi-catch lists related types, or whether a method must declare a checked exception. Runtime items ask what prints when a resource closes, a catch block throws again, or finally contains a return.

How it's tested

Expect snippets with nested try blocks, resources that print when closed, and catch blocks that rethrow. Some ask for output, others for the first line that fails to compile. Track which exception is currently propagating at each step, since the answer often depends on whether a later exception replaces or suppresses an earlier one.

  • Close order and output

    Resources print messages in close, the body throws, and you order the messages from body, close, catch and finally.

  • Unreachable or illegal catch

    Catch blocks are ordered from general to specific, or a multi-catch lists related types, and you choose the compile error.

  • Checked or unchecked

    A method throws a named exception, and you decide whether the caller must catch it or declare it with throws.

Reasoning it through

A try block throws IOException, and the single resource's close method throws IllegalStateException. Candidates often think the close exception replaces the first one. In try-with-resources the body's exception is primary, and the close exception is added to it with addSuppressed. A catch for IOException therefore runs, and calling getSuppressed on the caught exception returns an array holding the IllegalStateException.

Objectives 1

Official objectives from the Oracle outline, in outline order.

4.1 Handle exceptions using try/catch/finally, try-with-resources, and multi-catch blocks, including custom exceptions.Exception hierarchy, handler flow, resource management, multi-catch and custom exception classes.
What it means
Throwable has two branches: Error, for serious problems applications should not catch, and Exception. Exceptions other than RuntimeException and its subclasses are checked, so they must be caught or declared. A try block can be followed by catch blocks, a finally block or both, and try-with-resources closes AutoCloseable resources automatically.
What to understand
Catch blocks are tested in order, so a subclass must come before its superclass. A multi-catch such as catch (IOException | SQLException e) cannot list types related by inheritance, and its variable is implicitly final. Finally runs whether or not an exception occurs; a return inside finally overrides an earlier return or exception, which is legal but poor practice. In try-with-resources, resources close in reverse order after the try body and before any catch or finally block, and since Java 9 an effectively final variable can be named as a resource. Suppressed exceptions from close are available through getSuppressed. Custom exceptions extend Exception for checked behaviour or RuntimeException for unchecked, usually adding constructors that pass a message and cause to super. Overriding methods cannot throw new or broader checked exceptions.
How it shows up
Expect output ordering with resources and finally, illegal catch ordering, and methods that fail to declare a checked exception.
Common confusion
Believing catch runs before resources close, or that a multi-catch may list FileNotFoundException with IOException.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Checked exception

    Exception outside the RuntimeException branch.

    Remember
    Must be caught or declared with throws.
    Tested as
    Compile-error questions.
    Trap
    Treating IOException as unchecked.

  • Unchecked exception

    RuntimeException and its subclasses.

    Remember
    No catch or declaration required.
    Tested as
    Runtime output questions.
    Trap
    Adding needless throws and thinking it is required.

  • Catch ordering

    Handlers are checked top to bottom.

    Remember
    A superclass before a subclass makes the subclass catch unreachable.
    Tested as
    Compile-error spotting.
    Trap
    Expecting a warning rather than an error.

  • Multi-catch

    One handler for several unrelated types.

    Remember
    Types must not be subclass-related; the variable is final.
    Tested as
    Legality questions.
    Trap
    Assigning a new value to the catch variable.

  • finally

    Block that runs after try and catch in every normal path.

    Remember
    A return in finally overrides other outcomes.
    Tested as
    Output with returns.
    Trap
    Expecting the try block's return value to win.

  • try-with-resources

    Automatically closes AutoCloseable resources.

    Remember
    Close happens in reverse order before catch and finally.
    Tested as
    Output ordering.
    Trap
    Assuming close runs after finally.

  • Suppressed exception

    Secondary exception attached to the primary one.

    Remember
    Read with getSuppressed().
    Tested as
    Close-throws scenarios.
    Trap
    Thinking the close exception replaces the original.

  • Custom exception

    Your own subclass of Exception or RuntimeException.

    Remember
    Choose the parent based on checked behaviour.
    Tested as
    Design questions.
    Trap
    Extending Error or Throwable for application errors.

  • Overriding and throws

    Overrides may narrow but not broaden checked exceptions.

    Remember
    Unchecked exceptions can always be added.
    Tested as
    Inheritance plus exception questions.
    Trap
    Adding a new checked exception in a subclass.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Throwable branches

ConceptMeaningKey differenceCommon trap
Error Serious JVM or system problem Not meant to be caught by applications Catching StackOverflowError as normal flow
Checked Exception Recoverable condition the compiler tracks Catch or declare rule applies Forgetting throws on a method
RuntimeException Programming error such as a null dereference Compiler does not enforce handling Thinking it must be declared

Handler constructs

ConceptMeaningKey differenceCommon trap
try/catch/finally Manual handling and cleanup You write the cleanup code Forgetting finally runs even after return
try-with-resources Automatic closing of resources Closes in reverse order and records suppressed exceptions Using a type that is not AutoCloseable
Multi-catch Shared handler for unrelated types Variable is implicitly final Listing a subtype with its supertype

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Close after catch

    What candidates pick
    Orders output as body, catch, then close messages.
    Why it looks right
    Cleanup sounds like the last step.
    Why it's wrong
    Resources close immediately after the try body, before any catch or finally block executes.

    Clue to watch for Resources that print inside close().

  2. Declaration order closing

    What candidates pick
    Closes resources in the order they were declared.
    Why it looks right
    Opening and closing in the same order seems natural.
    Why it's wrong
    Resources close in reverse order, so the last one declared closes first.

    Clue to watch for Two or more resources in one try header.

  3. Related multi-catch

    What candidates pick
    Accepts catch (FileNotFoundException | IOException e).
    Why it looks right
    Both exceptions can occur when reading files.
    Why it's wrong
    FileNotFoundException is a subclass of IOException, so the alternatives are redundant and the code does not compile.

    Clue to watch for Exceptions from the same branch of the hierarchy.

  4. Close exception wins

    What candidates pick
    Says the exception from close propagates instead of the body's exception.
    Why it looks right
    It was thrown last.
    Why it's wrong
    When the body has already thrown, the close exception is added as suppressed to the primary exception.

    Clue to watch for Both the body and close() throw.

  5. Unreachable checked catch

    What candidates pick
    Accepts a catch for IOException around code that cannot throw it.
    Why it looks right
    Extra handling looks harmless.
    Why it's wrong
    Catching a checked exception the try block cannot throw is a compile error, unlike catching Exception or RuntimeException.

    Clue to watch for A try body with only arithmetic or println calls.

Answer framework

Apply these checks in order when reading an exception question.

  1. Classify every exception type in the code as Error, checked or unchecked, and check that each checked exception is caught or declared with throws.
  2. Verify the catch structure: subclasses before superclasses, no related types in multi-catch, and no catch for a checked exception the try body cannot throw.
  3. For try-with-resources, confirm each resource is AutoCloseable and list the close calls in reverse order of declaration, before catch and finally.
  4. Track the propagating exception step by step, noting when close adds a suppressed exception and when a catch block throws a new one.
  5. Finish with finally, checking whether it prints, returns or throws, since a return or throw there replaces whatever was propagating.

Practice question

A developer writes a closeable record to trace cleanup. What does this print? record R(String id) implements AutoCloseable { public void close() { System.out.print("c" + id); } } try (var a = new R("1"); var b = new R("2")) { System.out.print("t"); throw new IllegalStateException(); } catch (RuntimeException e) { System.out.print("x"); } finally { System.out.print("f"); }

Want more like this? The 1Z0-830 practice test has questions for every domain.

Checklist

0 of 10

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Learn this section by building a test harness. Write a record or class that implements AutoCloseable and prints in its constructor and close method, then combine two or three instances in one try header. Make the body throw, make close throw, and make both throw, printing getSuppressed each time. Running these variations once teaches the ordering rules better than reading about them.

Next, practise compile rules. Write catch blocks in the wrong order, multi-catch clauses with related types, and catches for checked exceptions the body cannot throw, and read each compiler message. Create a custom checked exception and a custom unchecked one, then override a method and try adding each to its throws clause.

Finish by writing a one-page flow chart: body, close in reverse order, catch, finally. Answer a set of practice items without a compiler, and for every miss, note which step of the chart you skipped. Two or three focused sessions are usually enough for this section.

FAQ

How much of 1Z0-830 is Domain 4, Handling Exceptions?

Oracle does not publish a weight for Handling Exceptions. It is a single objective, and we plan for roughly four of the 50 questions.

Is IOException checked?

Yes. IOException extends Exception but not RuntimeException, so code that can throw it must catch it or declare it.

Can try-with-resources have no catch or finally?

Yes. A try-with-resources statement is complete on its own, unlike a plain try block, which needs at least one catch or a finally.

What happens to an exception thrown by close?

If the body already threw, the close exception is suppressed and attached to the primary one. If the body completed normally, the close exception propagates itself.

Can I catch Error?

The compiler allows it, but applications should not normally catch Error subclasses such as OutOfMemoryError, because the program is unlikely to recover reliably.

Should custom exceptions be checked or unchecked?

Extend Exception when callers can reasonably recover and should be forced to handle it. Extend RuntimeException for programming errors such as invalid arguments.

Test your Domain 4 knowledge

You have reviewed checked and unchecked exceptions, catch ordering, multi-catch, finally, try-with-resources and custom exceptions. Test whether you can order output and spot illegal handlers.

Take the 1Z0-830 practice test Check your 1Z0-830 readiness

Keep going