Before Java 7, handling two unrelated exceptions with identical logic meant writing two identical catch blocks. Multi-catch eliminates that duplication. The syntax catch (IOException | SQLException exception) lets a single block handle multiple exception types when the response is the same. It was introduced in Java 7 as part of Project Coin — the same release that brought try-with-resources and the diamond operator. One syntax rule defines how it works: the exception types must not be in a subtype relationship with each other.

What Is Multi-catch?

Multi-catch is a catch clause that declares two or more exception types separated by the pipe character |. The JVM evaluates a multi-catch using the same instanceof logic as a single-type catch — if the thrown exception matches any of the listed types, that block executes.

SINGLE-CATCH (before Java 7):
  try {
      operation();
  } catch (IOException ioe) {
      log.error("IO failure", ioe);
      throw new ServiceException("Operation failed", ioe);
  } catch (SQLException sqle) {
      log.error("IO failure", sqle);          // IDENTICAL
      throw new ServiceException("Operation failed", sqle); // IDENTICAL
  }

MULTI-CATCH (Java 7+):
  try {
      operation();
  } catch (IOException | SQLException exception) {
      log.error("IO failure", exception);          // one block — DRY
      throw new ServiceException("Operation failed", exception);
  }
  The two forms produce identical bytecode — no performance difference.

Basic Overview — Multi-catch Rules and Behaviour

SYNTAX:
  catch (TypeA | TypeB | TypeC variableName) {
      // handle all three the same way
  }

RULE 1 — TYPES MUST NOT BE IN A SUBTYPE RELATIONSHIP:
  VALID   (no subtype relationship):
    catch (IOException | SQLException exception)
    catch (NullPointerException | IllegalArgumentException e)
    catch (IOException | InterruptedException | ClassNotFoundException e)

  INVALID (subtype relationship — compiler error):
    catch (IOException | FileNotFoundException e)
    → FileNotFoundException IS-A IOException — FileNotFoundException is already
      covered by IOException; the second type is redundant and the compiler rejects it.

RULE 2 — VARIABLE IS IMPLICITLY FINAL:
  catch (IOException | SQLException exception) {
      exception = new IOException("replaced"); // COMPILE ERROR — exception is final
  }
  This is because the variable's declared type is the common supertype (Exception
  in the above case), and allowing reassignment could break type safety across
  the listed types. The variable can be READ freely — just not reassigned.

RULE 3 — ONE VARIABLE FOR ALL LISTED TYPES:
  One variable — one reference to whichever exception was actually thrown.
  exception.getClass().getSimpleName() gives the actual runtime type.
  exception.getMessage() gives the message of the actual thrown exception.

WHEN TO USE MULTI-CATCH:
  The handling code is genuinely identical for all listed types.
  Log + rethrow pattern.
  Translate to a domain exception regardless of which infrastructure type threw.
  Alert + return fallback regardless of failure source.

WHEN NOT TO USE MULTI-CATCH:
  The handling differs by type — use separate catch blocks.
  One type is recoverable, the other is not.
  The response changes based on the exception's specific fields
  (e.g., getErrorCode() on SQLException vs getStatusCode() on HttpException).

Why Multi-catch Was Introduced

The problem multi-catch solves is the DRY violation that arises when multiple unrelated exception types require identical handling. Before Java 7, every exception type needed its own catch block — even when all blocks contained the same code.

Java

Try it out

// File: BeforeMultiCatchDemo.java

import java.io.IOException;
import java.sql.SQLException;

public class BeforeMultiCatchDemo {

    // PRE-JAVA 7: Every exception type that needs the same handling
    // requires its own separate catch block — duplication is unavoidable
    static void saveReportLegacy(String reportId) {
        try {
            loadFromDatabase(reportId);
            writeToFile(reportId);

        } catch (IOException ioException) {
            // --- DUPLICATED BLOCK START ---
            System.err.println("Infrastructure failure [IOException]: " +
                ioException.getMessage());
            notifyAdmin(ioException);
            // --- DUPLICATED BLOCK END ---

        } catch (SQLException sqlException) {
            // --- IDENTICAL CODE ---
            System.err.println("Infrastructure failure [SQLException]: " +
                sqlException.getMessage());
            notifyAdmin(sqlException);
            // --- IDENTICAL CODE ---
        }
        // When a third exception type is added — a third identical block appears
    }

    // JAVA 7+: single block handles both — same behaviour, no duplication
    static void saveReportModern(String reportId) {
        try {
            loadFromDatabase(reportId);
            writeToFile(reportId);

        } catch (IOException | SQLException exception) {
            System.err.println("Infrastructure failure [" +
                exception.getClass().getSimpleName() + "]: " + exception.getMessage());
            notifyAdmin(exception);
        }
    }

    static void loadFromDatabase(String id) throws SQLException {
        if (id.startsWith("DB-FAIL")) throw new SQLException("DB read failed for: " + id);
    }

    static void writeToFile(String id) throws IOException {
        if (id.startsWith("IO-FAIL")) throw new IOException("File write failed for: " + id);
    }

    static void notifyAdmin(Exception exception) {
        System.out.println("  [ADMIN NOTIFIED] " +
            exception.getClass().getSimpleName());
    }

    public static void main(String[] args) {

        System.out.println("=== Before multi-catch (legacy) ===");
        saveReportLegacy("REPORT-001");       // success
        saveReportLegacy("DB-FAIL-REPORT");   // SQLException
        saveReportLegacy("IO-FAIL-REPORT");   // IOException

        System.out.println();

        System.out.println("=== Modern multi-catch ===");
        saveReportModern("REPORT-001");
        saveReportModern("DB-FAIL-REPORT");
        saveReportModern("IO-FAIL-REPORT");
    }
}

Output:
=== Before multi-catch (legacy) ===
=== Modern multi-catch ===
Infrastructure failure [SQLException]: DB read failed for: DB-FAIL-REPORT
  [ADMIN NOTIFIED] SQLException
Infrastructure failure [IOException]: File write failed for: IO-FAIL-REPORT
  [ADMIN NOTIFIED] IOException

Infrastructure failure [SQLException]: DB read failed for: DB-FAIL-REPORT
  [ADMIN NOTIFIED] SQLException
Infrastructure failure [IOException]: File write failed for: IO-FAIL-REPORT
  [ADMIN NOTIFIED] IOException

How Multi-catch Works Internally

The Java compiler translates a multi-catch block into bytecode that has one handler per listed exception type, but all handlers share the same handler code. The exception variable holds whichever exception was actually thrown.

BYTECODE VIEW — multi-catch compiles to one handler per type, shared body:

  SOURCE:
    catch (IOException | SQLException exception) {
        log(exception);
    }

  EXCEPTION TABLE (compiled bytecode):
  ┌─────────────┬───────────┬──────────────┬──────────────┐
  │  from (PC)  │  to (PC)  │  handler (PC)│  exception   │
  ├─────────────┼───────────┼──────────────┼──────────────┤
  │     0       │    20     │      30      │  IOException │
  │     0       │    20     │      30      │  SQLException│
  └─────────────┴───────────┴──────────────┴──────────────┘

  Both types point to the SAME handler address (30).
  The handler at PC=30 is the multi-catch body — shared by both.
  This is identical to writing two separate catch blocks pointing to the same code.

WHY THE VARIABLE IS IMPLICITLY FINAL:
  When the compiler infers the type of the multi-catch variable, it chooses
  the common supertype of all listed exceptions — Exception (or the most
  specific common ancestor). But the thrown exception's actual type is only
  known at runtime. If reassignment were allowed, you could write:
    exception = new IOException("override"); // what type is exception now?
  To prevent ambiguity and preserve type safety across the listed types,
  the compiler makes the variable final.

ACTUAL TYPE AT RUNTIME:
  exception.getClass().getSimpleName() → "IOException" or "SQLException"
  depending on which one was actually thrown — not the inferred supertype.

Core Operations with Examples

Multi-catch With Rethrowing

A common production pattern: catch multiple infrastructure exceptions, log them uniformly, and rethrow as a domain exception. The original exception is always passed as the cause.

Java

Try it out

// File: MultiCatchRethrowDemo.java

import java.io.IOException;
import java.sql.SQLException;

public class MultiCatchRethrowDemo {

    // Domain exception — wraps infrastructure failures
    static class DataAccessException extends RuntimeException {
        DataAccessException(String operation, String detail, Throwable cause) {
            super("[" + operation + "] " + detail, cause);
        }
    }

    // Pattern 1: multi-catch + translate to domain exception
    static String fetchOrderDetails(String orderId) {
        try {
            return queryDatabase("SELECT * FROM orders WHERE id=" + orderId);
        } catch (IOException | SQLException exception) {
            // Translate: infrastructure exception → domain exception
            // ALWAYS pass the original as the cause — never lose the root chain
            throw new DataAccessException("FETCH_ORDER",
                "Failed to retrieve order: " + orderId, exception);
        }
    }

    // Pattern 2: multi-catch + log + rethrow the same exception (checked)
    static String loadTemplate(String templateName) throws IOException {
        try {
            return readFile("templates/" + templateName);
        } catch (IOException exception) {
            // Single type — log and rethrow, preserving the checked exception type
            System.err.println("Template load failed: " + exception.getMessage());
            throw exception; // rethrow the same exception unchanged
        }
    }

    // Pattern 3: multi-catch + log + rethrow as unchecked (checked → unchecked)
    static String buildReport(String reportId) {
        try {
            String data    = queryDatabase("SELECT * FROM reports WHERE id=" + reportId);
            String template = readFile("templates/report.html");
            return template.replace("{{data}}", data);
        } catch (IOException | SQLException exception) {
            System.err.println("Report generation failed [" +
                exception.getClass().getSimpleName() + "]: " + exception.getMessage());
            // Wrap as unchecked — callers do not need to handle infrastructure failures
            throw new DataAccessException("BUILD_REPORT",
                "Report unavailable: " + reportId, exception);
        }
    }

    static String queryDatabase(String sql) throws SQLException {
        if (sql.contains("FAIL-DB")) throw new SQLException("Query failed: " + sql);
        return "data-for-[" + sql.substring(sql.lastIndexOf('=') + 1) + "]";
    }

    static String readFile(String path) throws IOException {
        if (path.contains("FAIL-IO")) throw new IOException("Cannot read: " + path);
        return "content-of-" + path;
    }

    public static void main(String[] args) {

        System.out.println("=== Pattern 1: multi-catch + translate to domain exception ===");
        try {
            System.out.println(fetchOrderDetails("ORD-001"));   // success
            System.out.println(fetchOrderDetails("FAIL-DB-42")); // SQLException → DataAccessException
        } catch (DataAccessException dae) {
            System.out.println("DataAccessException: " + dae.getMessage());
            System.out.println("Root cause: [" +
                dae.getCause().getClass().getSimpleName() + "] " +
                dae.getCause().getMessage());
        }

        System.out.println();

        System.out.println("=== Pattern 3: multi-catch for report build ===");
        try {
            System.out.println(buildReport("RPT-001"));
            System.out.println(buildReport("RPT-FAIL-IO")); // IOException in readFile
        } catch (DataAccessException dae) {
            System.out.println("Report failed: " + dae.getMessage());
            System.out.println("Caused by: " + dae.getCause().getClass().getSimpleName());
        }
    }
}

Output:
=== Pattern 1: multi-catch + translate to domain exception ===
data-for-[ORD-001]
DataAccessException: [FETCH_ORDER] Failed to retrieve order: FAIL-DB-42
Root cause: [SQLException] Query failed: SELECT * FROM orders WHERE id=FAIL-DB-42

=== Pattern 3: multi-catch for report build ===
content-of-templates/report.html
Report failed: [BUILD_REPORT] Report unavailable: RPT-FAIL-IO
Caused by: IOException

The Implicitly Final Variable

The exception variable in a multi-catch block cannot be reassigned. Understanding this rule is important when the handling code needs to prepare a response based on the caught exception.

Java

Try it out

// File: MultiCatchFinalDemo.java

import java.io.IOException;
import java.sql.SQLException;

public class MultiCatchFinalDemo {

    static void demonstrateFinalRule() {

        try {
            if (System.currentTimeMillis() % 2 == 0) {
                throw new IOException("IO failure");
            } else {
                throw new SQLException("DB failure");
            }
        } catch (IOException | SQLException exception) {

            // Reading the variable — always allowed
            System.out.println("Exception type    : " + exception.getClass().getSimpleName());
            System.out.println("Exception message : " + exception.getMessage());
            System.out.println("Is IOException?   : " + (exception instanceof IOException));
            System.out.println("Is SQLException?  : " + (exception instanceof SQLException));

            // The variable is implicitly final — these would not compile:
            // exception = new IOException("new");  ← COMPILE ERROR
            // exception = null;                    ← COMPILE ERROR

            // To get type-specific information: use instanceof then cast
            if (exception instanceof SQLException sqle) {
                // Java 16+ pattern matching — combines check and cast
                // Here: sqle gives access to SQLException-specific methods like getSQLState()
                System.out.println("SQL state (if available): " + sqle.getSQLState());
            }
        }
    }

    // Comparing multi-catch final variable to single-catch (not final)
    static void compareFinalBehaviour() {
        System.out.println("\n--- Single catch: variable is NOT final (can reassign) ---");
        try {
            throw new IOException("original");
        } catch (IOException exception) {
            // In a SINGLE catch block, the variable is NOT implicitly final
            // This compiles fine (though reassigning is rarely useful)
            exception = new IOException("reassigned");
            System.out.println("Single catch after reassign: " + exception.getMessage());
        }

        System.out.println("\n--- Multi-catch: variable IS implicitly final ---");
        try {
            throw new IOException("original");
        } catch (IOException | RuntimeException exception) {
            // exception = new IOException("reassigned"); // COMPILE ERROR
            System.out.println("Multi-catch (cannot reassign): " + exception.getMessage());
        }
    }

    public static void main(String[] args) {
        demonstrateFinalRule();
        compareFinalBehaviour();
    }
}

Output:
Exception type    : IOException
Exception message : IO failure
Is IOException?   : true
Is SQLException?  : false

--- Single catch: variable is NOT final (can reassign) ---
Single catch after reassign: reassigned

--- Multi-catch (cannot reassign): original

When Not to Use Multi-catch

Multi-catch is appropriate when handling is genuinely identical. When different exception types require different responses, separate catch blocks remain the right choice.

Java

Try it out

// File: SeparateCatchDemo.java

import java.io.FileNotFoundException;
import java.io.IOException;
import java.sql.SQLException;

public class SeparateCatchDemo {

    // WRONG: multi-catch used when handling differs by type
    static void processOrderWrong(String orderId) {
        try {
            loadOrder(orderId);
        } catch (FileNotFoundException | SQLException exception) {
            // Both treated the same, but they need different responses:
            // FileNotFoundException → show user a "record not found" message
            // SQLException → retry or trigger DB failover
            System.out.println("Failed: " + exception.getMessage());
            // Caller has no way to know which type of failure occurred
        }
    }

    // CORRECT: separate catch blocks when handling genuinely differs
    static void processOrderCorrect(String orderId) {
        try {
            loadOrder(orderId);
        } catch (FileNotFoundException fnfe) {
            // Expected business condition: order file archived or moved
            System.out.println("Order not found [" + orderId +
                "] — may have been archived. Checking archive...");

        } catch (IOException ioe) {
            // I/O infrastructure problem: retry logic appropriate
            System.out.println("I/O error reading order [" + orderId +
                "] — scheduling retry: " + ioe.getMessage());

        } catch (SQLException sqle) {
            // Database failure: trigger failover or circuit breaker
            System.out.println("DB failure for order [" + orderId +
                "] — triggering DB failover: " + sqle.getMessage());
        }
    }

    static void loadOrder(String id) throws IOException, SQLException {
        if (id.startsWith("MISSING")) throw new FileNotFoundException("Not found: " + id);
        if (id.startsWith("IO-ERR")) throw new IOException("Disk error for: " + id);
        if (id.startsWith("DB-ERR")) throw new SQLException("Connection lost for: " + id);
        System.out.println("Order loaded: " + id);
    }

    public static void main(String[] args) {
        System.out.println("=== Separate catch blocks (different responses) ===");
        processOrderCorrect("ORD-9821");
        processOrderCorrect("MISSING-ORD-001");
        processOrderCorrect("IO-ERR-ORD-002");
        processOrderCorrect("DB-ERR-ORD-003");
    }
}

Output:
=== Separate catch blocks (different responses) ===
Order loaded: ORD-9821
Order not found [MISSING-ORD-001] — may have been archived. Checking archive...
I/O error reading order [IO-ERR-ORD-002] — scheduling retry: Disk error for: IO-ERR-ORD-002
DB failure for order [DB-ERR-ORD-003] — triggering DB failover: Connection lost for: DB-ERR-ORD-003

Real-World Example — Razorpay Payment Retry Service

Razorpay's payment retry service reads pending transactions from a database, processes each one, and handles the variety of infrastructure failures that can occur during a payment run. Network timeouts, database unavailability, and file access errors all require the same retry-and-alert response — a prime candidate for multi-catch. Transaction-specific business failures require distinct handling and use separate catch blocks.

Java

Try it out

// File: PaymentTransaction.java

public record PaymentTransaction(
        String transactionId,
        String merchantId,
        double amount,
        int    retryCount) {}

Java

Try it out

// File: PaymentRetryException.java

public class PaymentRetryException extends RuntimeException {

    private final String transactionId;
    private final String failureCategory; // "INFRASTRUCTURE", "BUSINESS", "SYSTEM"

    public PaymentRetryException(
            String transactionId, String failureCategory,
            String message, Throwable cause) {
        super(message, cause);
        this.transactionId   = transactionId;
        this.failureCategory = failureCategory;
    }

    public String getTransactionId()   { return transactionId;   }
    public String getFailureCategory() { return failureCategory; }
}

Java

Try it out

// File: PaymentRetryService.java

import java.io.IOException;
import java.sql.SQLException;
import java.util.List;

public class PaymentRetryService {

    private static final int MAX_RETRIES = 3;

    public void retryPendingPayments(List<PaymentTransaction> transactions) {
        System.out.printf("Processing %d pending transactions...%n%n",
            transactions.size());

        for (PaymentTransaction txn : transactions) {
            processWithRetry(txn);
            System.out.println();
        }
    }

    private void processWithRetry(PaymentTransaction txn) {
        System.out.printf("--- TXN: %s | Merchant: %s | Rs.%.2f | retry#%d ---%n",
            txn.transactionId(), txn.merchantId(), txn.amount(), txn.retryCount());

        try {
            // Step 1: Load transaction state from DB
            String txnState = loadTransactionState(txn.transactionId());

            // Step 2: Process through payment gateway
            String gatewayResponse = callPaymentGateway(txn);

            // Step 3: Persist the result
            persistResult(txn.transactionId(), gatewayResponse);

            System.out.println("  SUCCESS: " + gatewayResponse);

        } catch (IOException | SQLException infrastructureException) {
            // MULTI-CATCH: network timeout, DB connection failure, file I/O error
            // All infrastructure failures get the same response:
            // schedule for retry if under limit, alert team if over limit
            handleInfrastructureFailure(txn, infrastructureException);

        } catch (IllegalArgumentException businessException) {
            // SEPARATE CATCH: business rule violation — no retry appropriate
            // Invalid merchant, invalid amount, suspended account
            System.out.printf("  BUSINESS FAILURE [no retry]: %s%n",
                businessException.getMessage());
            markTransactionFailed(txn.transactionId(), businessException.getMessage());

        } catch (Exception unexpectedException) {
            // SEPARATE CATCH: unexpected failures — alert immediately
            System.out.printf("  UNEXPECTED [%s]: %s — triggering alert%n",
                unexpectedException.getClass().getSimpleName(),
                unexpectedException.getMessage());
        }
    }

    private void handleInfrastructureFailure(
            PaymentTransaction txn, Exception exception) {
        // getClass().getSimpleName() reveals which infrastructure layer failed
        System.out.printf("  INFRA FAILURE [%s]: %s%n",
            exception.getClass().getSimpleName(), exception.getMessage());

        if (txn.retryCount() < MAX_RETRIES) {
            System.out.printf("  QUEUED FOR RETRY (attempt %d of %d)%n",
                txn.retryCount() + 1, MAX_RETRIES);
        } else {
            System.out.printf("  MAX RETRIES REACHED — alerting on-call team%n");
        }
        // In production: throw new PaymentRetryException(txn.transactionId(),
        //     "INFRASTRUCTURE", "Infra failure after retry", exception);
    }

    // ---- Simulated operations that throw different exception types ----

    private String loadTransactionState(String txnId) throws SQLException {
        if (txnId.startsWith("DB-FAIL")) {
            throw new SQLException("Connection pool exhausted for txn: " + txnId);
        }
        return "PENDING";
    }

    private String callPaymentGateway(PaymentTransaction txn) throws IOException {
        if (txn.transactionId().startsWith("IO-FAIL")) {
            throw new IOException("Gateway timeout for txn: " + txn.transactionId());
        }
        if (txn.merchantId().equals("SUSPENDED")) {
            throw new IllegalArgumentException(
                "Merchant account suspended: " + txn.merchantId());
        }
        if (txn.amount() <= 0) {
            throw new IllegalArgumentException(
                "Invalid transaction amount: " + txn.amount());
        }
        return "CONFIRMED:" + txn.transactionId();
    }

    private void persistResult(String txnId, String result) throws SQLException {
        if (txnId.startsWith("PERSIST-FAIL")) {
            throw new SQLException("Write failed for txn: " + txnId);
        }
    }

    private void markTransactionFailed(String txnId, String reason) {
        System.out.printf("  Marked %s as FAILED: %s%n", txnId, reason);
    }

    public static void main(String[] args) {
        PaymentRetryService service = new PaymentRetryService();

        List<PaymentTransaction> batch = List.of(
            new PaymentTransaction("TXN-001",       "M-Swiggy",    899.0,  0),
            new PaymentTransaction("DB-FAIL-TXN-02","M-Zomato",    2499.0, 1),
            new PaymentTransaction("IO-FAIL-TXN-03","M-Meesho",    499.0,  2),
            new PaymentTransaction("DB-FAIL-TXN-04","M-CRED",      1299.0, 3), // max retries
            new PaymentTransaction("TXN-005",       "SUSPENDED",   599.0,  0), // business fail
            new PaymentTransaction("TXN-006",       "M-PhonePe",   -50.0,  0)  // invalid amount
        );

        service.retryPendingPayments(batch);
    }
}

Output:
Processing 6 pending transactions...

--- TXN: TXN-001 | Merchant: M-Swiggy | Rs.899.00 | retry#0 ---
  SUCCESS: CONFIRMED:TXN-001

--- TXN: DB-FAIL-TXN-02 | Merchant: M-Zomato | Rs.2499.00 | retry#1 ---
  INFRA FAILURE [SQLException]: Connection pool exhausted for txn: DB-FAIL-TXN-02
  QUEUED FOR RETRY (attempt 2 of 3)

--- TXN: IO-FAIL-TXN-03 | Merchant: M-Meesho | Rs.499.00 | retry#2 ---
  INFRA FAILURE [IOException]: Gateway timeout for txn: IO-FAIL-TXN-03
  QUEUED FOR RETRY (attempt 3 of 3)

--- TXN: DB-FAIL-TXN-04 | Merchant: M-CRED | Rs.1299.00 | retry#3 ---
  INFRA FAILURE [SQLException]: Connection pool exhausted for txn: DB-FAIL-TXN-04
  MAX RETRIES REACHED — alerting on-call team

--- TXN: TXN-005 | Merchant: SUSPENDED | Rs.599.00 | retry#0 ---
  BUSINESS FAILURE [no retry]: Merchant account suspended: SUSPENDED
  Marked TXN-005 as FAILED: Merchant account suspended: SUSPENDED

--- TXN: TXN-006 | Merchant: M-PhonePe | Rs.-50.00 | retry#0 ---
  BUSINESS FAILURE [no retry]: Invalid transaction amount: -50.0
  Marked TXN-006 as FAILED: Invalid transaction amount: -50.0

Performance Considerations

Multi-catch has identical runtime performance to equivalent separate catch blocks. The Java compiler translates both into the same bytecode structure — separate entries in the exception table pointing to the same handler address.

BYTECODE — both forms compile to the same exception table:

  SEPARATE CATCH BLOCKS:
    catch (IOException e)  { log(e); rethrow(e); }
    catch (SQLException e) { log(e); rethrow(e); }
  Exception table: two entries, two handler addresses — but bodies are duplicated in bytecode.

  MULTI-CATCH:
    catch (IOException | SQLException e) { log(e); rethrow(e); }
  Exception table: two entries, one shared handler address — body appears once in bytecode.

  MULTI-CATCH ADVANTAGE:
  - Smaller class file: handler body is compiled once, not twice
  - Zero runtime performance difference — same exception table lookup
  - Maintenance advantage: change the handler once, applies to all listed types

  CHOOSING BETWEEN MULTI-CATCH AND SEPARATE BLOCKS:
  Multi-catch   → when the response is genuinely identical for all types
  Separate      → when response differs by type, even slightly
  Performance   → never the deciding factor — they are bytecode-equivalent

Best Practices

Use multi-catch only when the handling is genuinely identical. The power of multi-catch is eliminating duplication. If you find yourself writing if (exception instanceof IOException) inside a multi-catch to do something different per type, you have separate concerns that belong in separate catch blocks. The exception types in a multi-catch should be interchangeable from the perspective of the handler code.

Always use exception.getClass().getSimpleName() in multi-catch log messages. The variable's declared type is the common supertype — but exception.getClass() gives the actual runtime type. A log message that says "Infrastructure failure" without the type is unhelpful. "Infrastructure failure [" + exception.getClass().getSimpleName() + "]" gives the exact class, which is essential for production monitoring dashboards that need to separate IOException spikes from SQLException spikes.

Always pass the exception as the cause when translating to a domain exception. throw new ServiceException("message", exception) preserves the full diagnostic chain. Never write throw new ServiceException(exception.getMessage()) — this loses the original exception type and stack trace, leaving only a string in the new exception's message.

Order the types in a multi-catch from most informative to least informative. While the compiler does not enforce ordering within a multi-catch (unlike the ordering of separate catch blocks), catch (SQLException | IOException e) reads as "database failure or I/O failure" — starting with the more domain-relevant type helps readers understand what failures are expected.

Common Mistakes

Mistake 1 — Using Multi-catch for Exception Types in a Subtype Relationship

Java

Try it out

// WRONG — FileNotFoundException IS-A IOException
// The compiler rejects this with: "Alternatives in a multi-catch statement cannot be related by subclassing"
try {
    readFile("data.txt");
} catch (IOException | FileNotFoundException exception) { // COMPILE ERROR
    System.out.println("File error: " + exception.getMessage());
}

// CORRECT — use only the supertype; it already catches the subtype
try {
    readFile("data.txt");
} catch (IOException exception) { // IOException catches FileNotFoundException too
    System.out.println("File error: " + exception.getMessage());
}

Mistake 2 — Trying to Reassign the Multi-catch Variable

Java

Try it out

// WRONG — the variable in a multi-catch is implicitly final
try {
    riskyOperation();
} catch (IOException | SQLException exception) {
    exception = new IOException("replacement"); // COMPILE ERROR
    // Cannot assign a value to final variable 'exception'
}

// CORRECT — if you need to work with a new exception, create a new variable
try {
    riskyOperation();
} catch (IOException | SQLException exception) {
    RuntimeException domainException =
        new ServiceException("Operation failed", exception);
    throw domainException; // new variable — no reassignment of the caught variable
}

Mistake 3 — Using Multi-catch and Losing Type-Specific Information

Java

Try it out

// WRONG — different exception types have different useful fields
// Using multi-catch erases the ability to access type-specific data
try {
    callService();
} catch (IOException | java.sql.SQLException exception) {
    // IOException has nothing special; SQLException has getSQLState(), getErrorCode()
    // These are lost when caught as the common supertype in multi-catch
    System.out.println("Failed: " + exception.getMessage()); // SQL state not logged
}

// CORRECT — use separate catch blocks when type-specific information matters
try {
    callService();
} catch (java.sql.SQLException sqlException) {
    System.out.printf("DB error [state=%s code=%d]: %s%n",
        sqlException.getSQLState(),      // type-specific: SQL state code
        sqlException.getErrorCode(),     // type-specific: vendor error code
        sqlException.getMessage());
} catch (IOException ioException) {
    System.out.println("IO error: " + ioException.getMessage());
}

Mistake 4 — Using Multi-catch With Types That Need Different Recovery Strategies

Java

Try it out

// WRONG — IOException and IllegalStateException need completely different responses
// IOException: retry the operation (transient infrastructure failure)
// IllegalStateException: fail immediately (programming error or invalid state)
try {
    processRequest(request);
} catch (IOException | IllegalStateException exception) {
    // Both treated as "log and return 500" — but IllegalStateException
    // should be treated as a bug that needs investigation, not a retry
    logger.error("Processing failed", exception);
    return Response.serverError();
}

// CORRECT — different recovery per type
try {
    processRequest(request);
} catch (IOException ioException) {
    logger.warn("Transient IO failure — will retry", ioException);
    return Response.serviceUnavailable();    // 503 — client can retry
} catch (IllegalStateException ise) {
    logger.error("Programming error — needs investigation", ise);
    return Response.serverError();          // 500 — do not retry
}

Interview Questions

Q1. What is multi-catch in Java and which version introduced it?

Multi-catch was introduced in Java 7 as part of Project Coin. It allows a single catch clause to handle multiple unrelated exception types using the pipe (|) separator: catch (IOException | SQLException exception). Before Java 7, each exception type required its own catch block — even when the handling was identical — leading to duplicated code. Multi-catch eliminates this duplication. The compiler translates both a multi-catch and equivalent separate catch blocks into the same exception table entries in bytecode, so there is no runtime performance difference between them.

Q2. Why is the variable in a multi-catch block implicitly final?

The Java Language Specification makes the multi-catch variable implicitly final to preserve type safety. When multiple exception types are listed, the variable's declared type is inferred as the common supertype — typically Exception. If reassignment were permitted, code could assign a new exception of a completely different type to the variable after the catch. Since the handler was written expecting one of the listed types, such reassignment could violate the intent and confuse static analysis tools. Making it final prevents this and keeps the variable's meaning clear: it holds exactly whichever exception was thrown.

Q3. What restriction applies to the exception types listed in a multi-catch?

The types must not be in a subtype relationship with each other. catch (IOException | FileNotFoundException e) is a compile error because FileNotFoundException extends IOException — listing both is redundant and the compiler rejects it. The correct form is just catch (IOException e), which already catches FileNotFoundException and all other IOException subclasses. The restriction exists because having a subtype and its supertype in the same multi-catch creates an ambiguity about which type "wins" — the compiler prevents it by requiring the types to be unrelated.

Q4. When should you use multi-catch versus separate catch blocks?

Use multi-catch when the handling code is genuinely identical for all listed exception types — the same log statement, the same domain exception thrown, the same fallback returned. Use separate catch blocks when the exception types need different responses: one type is recoverable and the other is not, the types have different domain-relevant fields (SQLException.getSQLState() vs no equivalent on IOException), or the types require different retry strategies or HTTP status codes. Multi-catch is a readability and DRY tool — it should not be used as a shortcut to ignore important distinctions between failure modes.

Q5. How does multi-catch interact with exception rethrowing?

Because the multi-catch variable is effectively typed as the common supertype at compile time, rethrowing it propagates the actual runtime type. If the handler throws exception (rethrows the same object), the runtime type (IOException or SQLException) is preserved — the exception behaves as its actual type in the caller's catch blocks. When you wrap the exception in a new domain exception, always pass it as the cause: throw new ServiceException("message", exception). This preserves the full chain — the domain exception's getCause() returns the actual IOException or SQLException that was thrown.

Q6. What does the compiler generate for a multi-catch block in bytecode?

The compiler generates one exception table entry per listed type, but all entries point to the same handler address (the shared catch body). With two types, there are two table rows — one for each type — but a single handler code block. This is different from two separate catch blocks, which would each have their own handler code. Multi-catch therefore produces a smaller class file when the two handlers would otherwise be identical. The runtime behaviour is identical to two separate handlers that happen to contain the same code.

FAQs

Can you use multi-catch with a custom exception and a standard exception?

Yes. catch (OrderNotFoundException | IOException exception) is valid as long as OrderNotFoundException is not a subclass of IOException (or vice versa). The only restriction is the subtype relationship. Custom exceptions and JDK exceptions can be freely mixed in multi-catch as long as they are unrelated in the hierarchy.

Can a multi-catch block contain more than two exception types?

Yes — there is no compiler limit on the number of types. catch (IOException | SQLException | ClassNotFoundException | InterruptedException exception) is valid. Each type adds an entry to the exception table, but all share one handler. In practice, more than three or four types in one multi-catch is a sign that the method may be doing too much — each additional type adds to the cognitive load of understanding what the catch block handles.

Does multi-catch affect the exception's stack trace?

No. Catching an exception in a multi-catch block does not modify the exception object in any way — its type, message, cause, and stack trace remain exactly as they were when the exception was constructed. exception.getStackTrace() returns the same data whether the exception was caught with a single-type catch, a multi-catch, or a supertype catch.

Can you use multi-catch for checked and unchecked exceptions in the same block?

Yes. catch (IOException | IllegalArgumentException exception) mixes a checked exception (IOException) and an unchecked one (IllegalArgumentException). This is syntactically valid. The distinction between checked and unchecked affects what the compiler enforces in the throws clause — it does not restrict which types can appear together in a catch clause.

What is the inferred type of the variable in a multi-catch?

The compiler infers the most specific common supertype of all listed exception types. For catch (IOException | SQLException e), the common supertype is Exception (both extend Exception without sharing a more specific common ancestor). For catch (NullPointerException | IllegalArgumentException e), the common supertype is RuntimeException (both extend it directly). This inferred type governs what methods are statically available on the variable — only methods defined on the inferred supertype are directly callable without casting.

Does multi-catch change which exceptions a method must declare in its throws clause?

No. Whether you use multi-catch or separate catch blocks does not affect what appears in a method's throws declaration. If you catch an exception inside the method (whether via single-type or multi-catch), it is handled — it does not need to be declared. If you rethrow a checked exception after catching it, it must appear in the throws clause. The throws clause is determined by what propagates out of the method, not by how the catch blocks are written internally.

Summary

Multi-catch eliminates the duplication that arises when multiple unrelated exception types require identical handling. The pipe-separated syntax catch (TypeA | TypeB variable) is compact, readable, and produces the same bytecode as equivalent separate catch blocks — there is no runtime cost difference.

Two rules govern correct multi-catch usage. The types must not be in a subtype relationship — the compiler enforces this. The variable is implicitly final — you cannot reassign it inside the block. Both exist to preserve type safety: the first prevents redundant catching, the second prevents unsafe reassignment of a variable whose type is inferred as a supertype.

The practical decision: multi-catch when handling is identical, separate catch blocks when handling differs by type. The most common multi-catch patterns in production code are log-plus-rethrow, infrastructure-exception-to-domain-exception translation, and alert-plus-fallback. Each of these applies the same response regardless of which specific infrastructure type threw — which is precisely what multi-catch was designed for.

What to Read Next

Continue Learning Exception Handling

Next Step

finally Block

Learn how to run cleanup code no matter what happens.

→

throws Keyword

Learn how a method can warn callers it might throw an exception.

→

try-with-resources

Learn how Java can close resources for you automatically.

→

CompletableFuture

Learn how to run tasks asynchronously and combine their results.