What Is Multi-catch and When Is It Useful?

Multi-catch lets a single catch clause handle several unrelated exception types. You write the alternatives separated by a pipe: catch (IOException | SQLException e). It removes a block of copy-pasted catch clauses that all did the same thing.

The useful case is a group of exceptions that are handled identically. A method that closes a resource and parses a value might fail with any of several unrelated checked exceptions, and the caller wants to log and continue in all of them. Writing three catch clauses with the same body is noise; multi-catch expresses the intent in one line.

Two rules make it work. The alternatives must be unrelated — none may be a subclass of another, because then the subtype would be unreachable and the compiler rejects it. And the caught variable's type is the least upper bound of the alternatives, so with IOException and SQLException you get something assignable to both, in practice Exception. That means you cannot call a method specific to one of them without casting, which is the price of the shorthand.

Multi-catch is not a licence to catch everything. Catching Exception and RuntimeException together is legal but usually wrong, because it swallows the programming errors you wanted to see. The rule of thumb is that multi-catch is for types you genuinely handle the same way, and the more specific the list, the better.

You list the types separated by a pipe inside a single catch clause. The variable that follows has the nearest common supertype of the alternatives, so you can call any method that type provides, and you can narrow it further with instanceof if you need the specific behaviour of one of them.

import java.io.IOException;

public class Main {
    public static void main(String[] args) {
        try {
            load();
        } catch (IOException | RuntimeException e) {
            System.out.println("caught    : " + e.getClass().getSimpleName());
            System.out.println("is IO?    : " + (e instanceof IOException));
            // The variable is effectively final, so it can be passed on.
            report(e);
        }
    }

    static void load() throws IOException {
        throw new IOException("cannot load");
    }

    static void report(Exception e) {
        System.out.println("reporting : " + e.getMessage());
    }
}

The output shows the three things you can do with the caught variable. You can print its runtime type, which tells you which alternative actually fired. You can test it with instanceof to narrow it when the handling differs. And you can pass it to another method, because in a multi-catch block the variable is implicitly final — you cannot reassign it, but you can hand it around, which is exactly what you want when you are delegating the handling to a logging helper.

That last point is worth dwelling on, because it is a deliberate design choice. A multi-catch variable is effectively final so that it can be captured by a lambda without any copying. That matters when you want to log asynchronously — you can pass the exception into an executor and it stays valid there, rather than being a mutable variable that another thread might change.

Because the compiler makes it implicitly final, and the reason is lambda capture. If you want to hand the exception to an asynchronous logger or to a stream operation, the variable has to be effectively final for the lambda to be able to capture it. An ordinary catch variable is mutable — you can reassign it — and that would break the capture rules, so the compiler forbids reassignment in a multi-catch block instead.

The restriction bites in a specific scenario: you want to catch several types, narrow to the one that actually occurred, and then work with a variable of that narrowed type. The classic solution is to assign the caught exception to a new local variable of the narrow type inside the block, which is allowed because the new variable is not the multi-catch variable itself.

There is a subtler form of the same restriction that catches people out. The multi-catch variable's static type is the least upper bound of the alternatives, so when you catch IOException | SQLException the variable is typed as Exception and you cannot call an IOException-specific method on it directly. You have to narrow it — with an instanceof test, or with a pattern-matching instanceof that binds a variable of the specific type.

So if you genuinely need per-type handling, the honest answer is that multi-catch is the wrong tool. Write separate catch clauses, one per type, each doing its own thing. Multi-catch is for when the handling really is identical, and forcing it onto cases that need different treatment is how you end up with a chain of instanceof checks inside a single catch block — which is more code than the separate clauses you were trying to avoid.