استثناها و مدیریت خطاExceptions & Error Handling

Welcome. This is one of those topics everyone thinks they've mastered — right up until an interviewer asks "exactly what happens when a finally block has a return?" or "why does my production NPE have no stack trace?". Our goal is that by the end of this chapter you don't just know the answers, you understand why they're true. We'll build every technical word from the ground up — no jargon dropped without unpacking it.

Part 0 — words you must know

Before we start, let's build the four words we'll lean on all chapter, each with an analogy. Nail these and the rest flows.

• Throwable: in Java, anything you can "throw" is an object of type Throwable. It is the only type the throw and catch keywords work with. Picture it as an error-report envelope traveling up your hand.
• throw: means "something broke — take this report envelope and pass it up."
• catch: means "I accept responsibility for this envelope and will deal with it."
• Unwinding: when the envelope is thrown and nobody catches it at the current frame, Java starts lifting plates off one at a time — deleting each frame and discarding its locals — until it reaches a frame with a matching catch. That step-by-step frame removal is called unwinding.

What an exception really is — the mental model

Now the technical name: an exception is a non-local transfer of control. Let me unpack that phrase. "Control" is which line of code is running right now. "Non-local transfer" means that control jumps not to the next line (which would be "local"), but somewhere far away — several frames down the stack. When a method cannot fulfill its contract, it abandons the normal return path and unwinds the stack until some frame catches it. The value that travels up the stack is that Throwable object.

Two consequences fall out of this definition, and they explain almost every design decision in the JVM:

A golden design rule: build your exceptions so that for someone reading the log bleary-eyed at 3 a.m., they answer three questions: what failed, why, and with what context. If your log doesn't say all three, that person (who may be future-you) burns hours.

The Throwable hierarchy

Now that you know every error is a Throwable object, let's see the whole family. Know this map like the back of your hand:

Object
 └─ Throwable                (has message, cause, stackTrace, suppressed[])
     ├─ Error                (serious, usually unrecoverable — don't catch)
     │   ├─ OutOfMemoryError
     │   ├─ StackOverflowError
     │   ├─ VirtualMachineError
     │   └─ AssertionError
     └─ Exception
         ├─ RuntimeException (UNCHECKED)
         │   ├─ NullPointerException
         │   ├─ IllegalArgumentException / IllegalStateException
         │   ├─ IndexOutOfBoundsException
         │   ├─ ClassCastException
         │   └─ ArithmeticException, ...
         └─ (everything else)  CHECKED
             ├─ IOException
             ├─ SQLException
             └─ InterruptedException, ...

The compiler's rule for the checked/unchecked line is purely syntactic — it looks only at the inheritance tree, not at meaning:

Throwable is the only type you can throw or catch. Learn its key fields, because we keep coming back to them:

Error vs Exception

Let's sharpen the factory picture. Error signals conditions the application normally cannot recover from: either the JVM itself is compromised (OutOfMemoryError when memory runs out, StackOverflowError when infinite recursion fills the stack), or an invariant the compiler had guaranteed was violated at runtime (NoClassDefFoundError, AssertionError).

A quick pause on "invariant": an invariant is something that must always stay true — like the rule "any class that compiled will be found at runtime." When such a rule breaks, a fundamental assumption of your world is broken, and continuing is meaningless.

Checked vs unchecked — the great design debate

This is the most contested API decision in Java's history, and interviewers use it to check whether you hold a reasoned position or just parrot the rule.

The argument for checked: they are part of the method signature — a compile-time contract that forces the caller to acknowledge a recoverable failure. When Files.newInputStream declares it can throw IOException, that is genuine documentation the compiler enforces; you can't ignore it.

The argument against: checked exceptions scale badly — meaning the bigger and more layered your program, the disproportionately worse the pain. Three reasons:

• They break lambdas and streams, because functional interfaces like Function don't declare throws at all.
• They leak implementation details up through abstraction layers — the upper layer shouldn't know the bottom uses SQL, but SQLException forces it to.
• They push developers toward the two worst anti-patterns in the language:

// Anti-pattern 1: swallow. Now the failure is invisible.
try { risky(); } catch (IOException e) { /* nothing */ }

// Anti-pattern 2: throws Exception everywhere, defeating the purpose.
void doWork() throws Exception { ... }

Modern practice — and every major framework since Spring — leans unchecked by default. Spring, for example, precisely catches SQLException and translates it into an unchecked hierarchy called DataAccessException, so your business code isn't littered with catch (SQLException).

try-with-resources, AutoCloseable, and suppressed exceptions

Before Java 7, correct resource cleanup required that notorious nested-finally dance — with a null check and a second try inside the finally. Ugly and error-prone. Java 7 replaced it with try-with-resources. Any type that implements the AutoCloseable interface can be declared in the "resource header" (the parentheses after try).

A fine point: AutoCloseable has a subtype called Closeable that just narrows the close() signature to throw IOException (suited to I/O classes).

try (var in = Files.newInputStream(path);
     var out = Files.newOutputStream(dest)) {   // resources declared here
    in.transferTo(out);
}   // close() called automatically, in REVERSE order: out first, then in

Two guarantees are easy to state but easy to get wrong in interviews:

Let me unpack guarantee two, because that's where everyone stumbles. Suppose the try body throws an exception and, while closing, close() throws another. Which reaches the caller? The body's exception propagates (it's the original, more important error), and each close exception is attached to it via the method Throwable.addSuppressed. You can later retrieve them with getSuppressed(). This is exactly the reverse of the pre-Java-7 world, where the finally's exception silently clobbered and lost the real one.

class Resource implements AutoCloseable {
    final String name;
    Resource(String name) { this.name = name; }
    void use() { throw new RuntimeException("boom in body"); }
    public void close() { throw new IllegalStateException("boom closing " + name); }
}

try (var r = new Resource("R1")) {
    r.use();
}
// Propagates: RuntimeException "boom in body"
// getSuppressed()[0] == IllegalStateException "boom closing R1"

Connection conn = dataSource.getConnection();   // effectively final
try (conn) {
    ...
}

finally: control-flow gotchas

finally is powerful: it runs no matter what — whether the body completes normally, an exception is caught, or an exception is in transit through it. But that very power hides several traps that show up constantly in senior interviews. Let's dissect all three.

Trap 1: return in finally swallows everything

static int f() {
    try {
        return 1;
    } finally {
        return 2;   // this return WINS; the try's return 1 is discarded
    }
}
// f() == 2

Why? Because finally gets the last word. When it reaches return 2, it effectively says "forget what you said before, the final answer is 2." Worse, a return (or throw) in finally can also silently swallow an in-flight exception:

static int g() {
    try {
        throw new RuntimeException("real error");
    } finally {
        return -1;   // exception vanishes; caller sees -1, never the throw
    }
}

Trap 2: finally does NOT change an already-evaluated return value

static int h() {
    int x = 1;
    try {
        return x;    // the VALUE 1 is captured onto the operand stack HERE
    } finally {
        x = 2;       // mutating the local now has no effect on the return
    }
}
// h() == 1

Let's watch the mechanism precisely. When Java reaches return x, it first fully evaluates the expression x and stashes the result — the number 1 — somewhere (on the "operand stack," a temporary work area). Then finally runs. Now x = 2 only changes the local variable x, but that stashed number 1 stays untouched. So the output is 1.

Trap 3: exception in try + exception in finally

try {
    throw new IOException("A");
} finally {
    throw new IllegalStateException("B");   // B propagates, A is LOST (not suppressed!)
}

The key point here: unlike try-with-resources, which we saw suppresses (not loses) extra exceptions, a plain finally does no auto-suppression. Exception B replaces A, and A vanishes completely — with no trace. If you must run cleanup that can throw, either wrap it in an inner try/catch or use try-with-resources so the primary exception survives.

Custom exceptions and exception translation

Instead of throwing a raw RuntimeException, define a small, meaningful hierarchy for your own domain (your business). And always provide a constructor that accepts a cause, so chaining works:

public class OrderNotFoundException extends RuntimeException {
    private final long orderId;

    public OrderNotFoundException(long orderId) {
        super("Order not found: " + orderId);
        this.orderId = orderId;
    }
    public OrderNotFoundException(long orderId, Throwable cause) {
        super("Order not found: " + orderId, cause);
        this.orderId = orderId;
    }
    public long orderId() { return orderId; }
}

Exception translation means catching a low-level exception at an abstraction boundary and rethrowing a higher-level one — while preserving the original exception as the cause:

public Order load(long id) {
    try {
        return repository.findById(id);
    } catch (SQLException e) {
        // Translate persistence detail into a domain-level failure,
        // but KEEP the SQLException as the cause for the log.
        throw new OrderLoadException("Failed to load order " + id, e);
    }
}

It's that chained cause that makes the stack trace show the golden Caused by: java.sql.SQLException... line.

Best practices

Keep these as a mental checklist:

• Fail fast. Validate arguments right at method entry and throw IllegalArgumentException / NullPointerException immediately — with Objects.requireNonNull(x, "x"). A crash near the cause is worth ten hours of debugging corrupted state far downstream.
• Never swallow. An empty catch block is a bug. At minimum, log at ERROR with context. If you truly intend to ignore it, name the variable ignored and add a comment stating why.
• Wrap with context, not noise. Add what the low level didn't know: which order id, which file, which retry attempt. But don't wrap-and-rethrow at every layer — that just builds a stack of near-identical messages.
• Catch narrow, catch late. Catch the most specific type you can actually handle; let everything else propagate to a single top-level handler (a servlet filter, a @ControllerAdvice, or an UncaughtExceptionHandler).
• Don't log and rethrow. Pick one: either handle it (log + recover) or propagate it. Doing both produces duplicate stack traces in the log, which is confusing.
• Preserve the interrupt. When you catch InterruptedException and can't propagate it, restore the flag: Thread.currentThread().interrupt();. Swallowing it makes threads un-cancellable. (More on this a few lines down.)
• Use multi-catch for shared handling: catch (IOException | SQLException e). Here the variable e is implicitly final.

Performance: the real cost of exceptions

Here's where many people misunderstand. Question: which part of an exception is expensive?

That "photographer" is a native method called fillInStackTrace(), invoked in the Throwable constructor, which walks the current thread's stack and snapshots every frame. Its cost scales with the depth of the stack. This is why throwing is orders of magnitude slower than a normal return, and precisely why "exceptions-as-control-flow" is an anti-pattern.

Two facts a senior must know:

public final class NoStackException extends RuntimeException {
    public NoStackException(String msg) {
        // message, cause, enableSuppression=false, writableStackTrace=false
        super(msg, null, false, false);
    }
}
// No fillInStackTrace cost. Nearly as cheap as a return.

Optional / result types vs exceptions

Exceptions are for the exceptional — conditions the immediate caller usually can't foresee at that call site. For expected absence or predictable domain failure, prefer a return-based signal:

• Optional<T> for "the value might legitimately not exist." For example, repository.findById(id) returning Optional<Order> is cleaner than throwing, since "not found" is a normal state.
• A Result / Either type — a sealed interface that makes both the success and failure branches explicit in the type system and forces the caller to handle failure. This is the same benefit as checked exceptions but without the syntactic pain, and it composes nicely through streams and map/flatMap.

sealed interface Result<T> permits Ok, Err {}
record Ok<T>(T value) implements Result<T> {}
record Err<T>(String reason) implements Result<T> {}

Error handling across async boundaries

The moment work leaves the calling thread, the natural throw/catch linkage is severed. You must re-plumb it. Let's see three scenarios.

ExecutorService.submit vs execute

submit captures any thrown exception inside the Future it returns; that exception only surfaces when you call future.get() — and then it comes out wrapped in an ExecutionException. If you never call get(), the failure stays silent — a classic production ghost that costs hours. By contrast, execute has no Future, so an uncaught exception goes straight to the thread's UncaughtExceptionHandler.

Future<?> f = executor.submit(task);
try {
    f.get();
} catch (ExecutionException e) {
    Throwable real = e.getCause();   // the actual exception the task threw
    ...
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();   // restore the flag
}

CompletableFuture

Here exceptions are captured and re-thrown at consumption, but the wrapper around them differs: get() throws an ExecutionException, while join() throws an unchecked CompletionException. It's best to handle failures inside the pipeline:

CompletableFuture
    .supplyAsync(this::loadUser)
    .thenApply(this::enrich)                 // skipped if loadUser failed
    .exceptionally(ex -> fallbackUser())     // recover, returns a User
    .handle((user, ex) -> ex == null         // see BOTH result and error
        ? Response.ok(user)
        : Response.error(ex.getCause()));

Virtual threads (Java 21)

Here's the good news. Each task runs on its own virtual thread, so exceptions behave like ordinary blocking code again — a try/catch around the blocking call works normally, and an uncaught exception ends only that one virtual thread.

Structured concurrency — via the StructuredTaskScope class, which arrived as a preview in Java 21 — makes this rigorous. With ShutdownOnFailure, if any forked subtask throws, its siblings are cancelled and the exception surfaces at join()/throwIfFailed() — restoring the parent-child exception relationship that raw executors had lost:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var user  = scope.fork(this::fetchUser);
    var order = scope.fork(this::fetchOrder);
    scope.join().throwIfFailed();            // propagates the first failure
    return combine(user.get(), order.get());
}   // scope auto-closed; all subtasks guaranteed done or cancelled

Interview Questions

Now it's practice time. Answer each yourself first, then read the answer.

static int f() {
    try { return 1; } finally { return 2; }
}

static int h() {
    int x = 1;
    try { return x; } finally { x = 2; }
}

try {
    process();
} catch (Exception e) {
    throw new ServiceException("processing failed");   // <-- bug
}

Senior notes & advanced edge cases

By now you understand the language-level mechanics of exceptions. What separates a senior from a strong mid-level engineer is what happens once an exception escapes a single method and enters a real system: a database transaction, the HTTP boundary, your logs, a class-loader boundary, retries, and reactive pipelines. That is exactly where production catches fire — and where senior interviews probe.

Exceptions vs the database transaction — the senior trap #1

Here is Spring's default that surprises even experienced developers and silently corrupts data:

@Transactional
public void placeOrder(Order o) throws PaymentException {   // PaymentException extends Exception
    orderRepo.save(o);          // this INSERT stays committed...
    charge(o);                  // ...even if PaymentException is thrown here!
}

Why? This default is inherited from the EJB contract, where checked meant "recoverable business failure" and unchecked meant "system error." The explicit fix:

@Transactional(rollbackFor = PaymentException.class)   // now it rolls back
public void placeOrder(Order o) throws PaymentException { ... }

Exceptions at the HTTP boundary — from @ControllerAdvice to ProblemDetail

Once an exception reaches the top of the stack, it must be translated into an HTTP response — not dumped on the user as a raw stack trace. Spring's standard pattern is a single centralized handler:

Error flow from deep inside the service up to the client's standardized response:

flowchart LR
  Ctrl[Controller] --> Svc[Service]
  Svc --> Repo[(Repository)]
  Repo -- SQLException --> Svc
  Svc -- domain exception --> Advice[@ControllerAdvice]
  Advice --> PD[ProblemDetail RFC 9457]
  PD --> Client[HTTP 4xx/5xx JSON]

@RestControllerAdvice
class GlobalErrors extends ResponseEntityExceptionHandler {

    @ExceptionHandler(OrderNotFoundException.class)
    ProblemDetail handleNotFound(OrderNotFoundException ex) {
        var pd = ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, ex.getMessage());
        pd.setType(URI.create("https://api.example.com/errors/order-not-found"));
        pd.setProperty("orderId", ex.orderId());   // non-standard extension field
        return pd;   // served with media type application/problem+json
    }
}

Helpful NullPointerException — why an NPE talks today

How is that possible? At the moment of the throw the JVM analyzes the bytecode to determine which instruction (getfield, invokevirtual, aload) operated on what, and reconstructs the variable name from the LocalVariableTable — which is fully accurate only when the code was compiled with debug info (-g). Building this message has a small cost, so it runs only when an NPE actually fires, never on the hot path.

The class-loader trap — the "poisoned" class and ExceptionInInitializerError

This is one of the most insidious production bugs, and few people explain it correctly.

If a static { ... } block or a static field initializer throws, the JVM wraps it in ExceptionInInitializerError and moves the class into a "failed initialization" state:

class Config {
    static final String URL = load();   // if load() throws...
    static String load() { throw new IllegalStateException("bad config"); }
}

Logging exceptions correctly — the most common everyday mistake

// wrong — trace destroyed
log.error("failed to load order " + id + ": " + e);
// right — parameterized, exception last
log.error("failed to load order {}", id, e);

Short senior facts that win interviews

void m() throws IOException, SQLException {
    try { risky(); }
    catch (Exception e) {   // e is never reassigned → effectively final
        log.warn("retrying");
        throw e;   // compiler knows it's only IOException or SQLException, not any Exception
    }
}

Reactive boundaries and retry logic

If you work with Project Reactor (WebFlux), a try/catch is useless because the error happens when the pipeline executes, not when it is built. The error travels as an onError signal through the stream:

orderService.load(id)                       // Mono<Order>
    .onErrorResume(NotFoundException.class,  // like catch, but in-stream
        e -> Mono.just(Order.empty()))
    .doOnError(e -> log.error("load failed", e))   // side-effect, doesn't change the stream
    .retryWhen(Retry.backoff(3, Duration.ofMillis(200)));