Exception Handling

Throwable is the root of everything that can be thrown. It has two direct subclasses: Error (serious JVM or environment problems) and Exception. RuntimeException extends Exception.

• Error and RuntimeException (with their subclasses) are unchecked.
• All other Exception subclasses, and Throwable itself, are checked.
• Only Throwable instances can appear in throw and catch.

Checked exceptions must be caught or declared in throws; the compiler enforces it. Unchecked exceptions (RuntimeException, Error) are not enforced.

• Checked: recoverable conditions the caller can reasonably handle (I/O, parsing external data).
• Unchecked: programming errors (NullPointerException, IllegalArgumentException) or unrecoverable failures.
• Checking exists only at compile time; the JVM does not distinguish them.

Use checked when the caller can realistically recover and you want to force them to consider it; use unchecked for precondition violations and for failures the caller cannot meaningfully handle.

• Modern libraries (Spring, Hibernate) prefer unchecked exceptions because checked ones leak through layers and pollute signatures.
• Checked exceptions do not compose well with lambdas and streams.
• Never choose checked just to "make callers careful"; they tend to wrap or swallow.

The try block runs; if it throws, the first matching catch (top to bottom) runs; finally runs afterwards in every case, whether or not an exception occurred or was caught.

• If no catch matches, finally still runs and the exception then propagates.
• A catch for a superclass placed before a subclass is a compile error (unreachable).
• Only System.exit, Runtime.halt, JVM crash or thread death/never-ending loop prevent finally.

A return in finally overrides any earlier return value and discards any exception in flight. It is considered a serious bug.

static int f() {
    try { throw new RuntimeException("x"); }
    finally { return 1; }   // exception swallowed, returns 1
}

• The same applies to break and continue that leave the finally block abruptly.
• javac warns with -Xlint:finally; static analysis tools flag it.

The return value is evaluated and saved before finally runs, so a later modification of a primitive local does not affect it.

static int f() {
    int x = 1;
    try { return x; }
    finally { x = 2; }
}
// returns 1

• For a reference type the reference is saved, but mutations of the object itself are visible to the caller.

If a finally block (or a close in older code) throws, its exception replaces the one thrown from the try block; the original is lost without any trace.

• Also lost by return/break in finally, empty catch blocks, and catching then throwing a new exception without the cause.
• try-with-resources fixes the first case by attaching the close failure as a suppressed exception.

It declares resources in the try header; each is closed automatically in reverse order of declaration when the block exits, normally or exceptionally. Resources must implement AutoCloseable.

• Closeable extends AutoCloseable; its close() throws IOException and is idempotent by contract.
• Java 9+ allows an effectively final existing variable: try (r) { ... }.
• Null resources are skipped without NPE.

If the try body throws and close() also throws, the body exception is the primary one and the close exception is attached via addSuppressed. Retrieve with getSuppressed().

• If only close() throws, that exception is primary.
• Multiple resources can each add a suppressed exception.
• printStackTrace shows them under "Suppressed:".

Resources are closed before any catch or finally block of the same statement runs.

• Sequence: resource init, body, close resources (reverse order), catch, finally.
• The catch therefore cannot use the resource (it is out of scope and already closed).
• Exceptions thrown from close are catchable by that same try statement's catch clauses.

Java 7 allows catch (IOException | SQLException e) to share one handler. The parameter is implicitly final.

• Alternatives cannot be related by subclassing (IOException | FileNotFoundException is a compile error).
• The static type of e is the least upper bound of the alternatives.

Since Java 7, if a catch parameter is effectively final and you throw e, the compiler treats the thrown types as the checked exceptions the try block can actually throw, not the declared catch type.

void m() throws IOException {
    try { read(); }              // throws IOException
    catch (Exception e) { throw e; }  // legal: only IOException possible
}

• Reassigning e disables this analysis.

throw is a statement that throws one exception instance. throws is a method-signature clause declaring checked exception types the method may propagate.

• throws is part of the method contract, not the signature for overloading.
• Overriding methods cannot throw broader checked exceptions than the overridden one.

An overriding method may throw no new or broader checked exceptions than the overridden method; it may throw fewer, narrower, or none. Unchecked exceptions are unrestricted.

• Constructors are not overridden, but a subclass constructor must declare any checked exception from the super constructor it calls.
• The rule maintains substitutability through the supertype reference.

An exception can wrap another via new MyException("msg", cause) or initCause. getCause() returns it, and stack traces print "Caused by:" sections.

• Always preserve the cause when translating exceptions; losing it destroys the root-cause trace.
• initCause can be called once, only if the cause was not set by the constructor.

getMessage() returns the detail message (may be null). toString() returns ClassName: message (or just class name when message is null). getLocalizedMessage() defaults to getMessage() and can be overridden for i18n.

• Logging e.getMessage() alone loses the type and stack trace; NullPointerException often has a null or helpful message depending on version.

Since Java 14 (default on from 15), the JVM computes a message describing what was null, such as Cannot invoke "String.length()" because "s" is null.

• Local variable names appear only if compiled with -g; otherwise <local1>.
• Message is computed lazily on getMessage().

Error signals abnormal conditions from the JVM or environment (OutOfMemoryError, StackOverflowError, NoClassDefFoundError) that applications generally should not catch. Exception covers conditions an application may handle.

• Catching Error is allowed technically, but program state may be inconsistent.
• Legitimate cases: logging and graceful shutdown, a container isolating tasks, catching StackOverflowError in a recursive parser guard.

Thread stack exhaustion, usually from unbounded or very deep recursion. Each call pushes a frame; the stack size is set by -Xss (default ~512KB-1MB).

• Fix by adding a base case, converting to iteration, or using an explicit stack.
• Increasing -Xss only delays it, and costs memory per thread.
• Also caused by cyclic toString/hashCode/equals between bidirectional JPA entities or Lombok.

OOM is thrown when the JVM cannot allocate memory and GC cannot free enough. The message identifies the area.

• Java heap space: live data exceeds -Xmx or a leak.
• GC overhead limit exceeded: GC consumes nearly all time recovering little.
• Metaspace: too many classes (classloader leak).
• unable to create native thread: OS thread/memory limit.
• Direct buffer memory: off-heap NIO limit.
• Use -XX:+HeapDumpOnOutOfMemoryError to capture a dump for analysis.

Creating a Throwable is expensive because fillInStackTrace() walks and records the whole stack; throwing and unwinding is comparatively cheap, especially when the JIT inlines the throw and catch.

• Cost grows with stack depth (deep Spring/servlet stacks make it worse).
• Avoid exceptions for normal control flow in hot paths.
• Mitigate: reuse preallocated exceptions, override fillInStackTrace, or use the 4-arg constructor with writableStackTrace=false.

Extend RuntimeException (or Exception for recoverable checked cases), provide constructors for message and message+cause, and add structured fields like an error code instead of parsing messages.

public class OrderNotFoundException extends RuntimeException {
    private final long orderId;
    public OrderNotFoundException(long orderId) {
        super("Order not found: " + orderId);
        this.orderId = orderId;
    }
    public long getOrderId() { return orderId; }
}

• Keep a small, meaningful hierarchy; one base type per module.
• Exceptions are Serializable; keep fields serializable or transient.

Catching a low-level exception and throwing a higher-level one appropriate to the abstraction, with the original as cause. Example: SQLException becomes DataAccessException.

• Prevents leaking implementation details (JDBC, HTTP client) through layers.
• Spring's @Repository plus PersistenceExceptionTranslationPostProcessor translates persistence exceptions automatically.
• Always pass the cause.

It hides bugs, catches unexpected unchecked exceptions, may catch InterruptedException and Error, and prevents specific recovery.

• Acceptable at boundaries: request handlers, thread run loops, scheduled jobs, where you must log and continue.
• Catch the narrowest type you can handle.

Either propagate it or restore the flag with Thread.currentThread().interrupt() before returning; never swallow it.

try { queue.take(); }
catch (InterruptedException e) {
    Thread.currentThread().interrupt();
    return;
}

• Throwing InterruptedException clears the interrupt flag, so catching it without restoring loses the signal.

An exception escaping a static initializer is wrapped in ExceptionInInitializerError; the class is then unusable, and later access throws NoClassDefFoundError.

• ExceptionInInitializerError carries the real exception as its cause.
• The first failure shows the root; subsequent ones do not, making logs misleading.

Standard functional interfaces do not declare checked exceptions, so a lambda body cannot throw them. Catch inside the lambda and wrap in an unchecked exception, or define your own functional interface that throws.

@FunctionalInterface interface ThrowingFn<T, R> { R apply(T t) throws Exception; }
static <T, R> Function<T, R> unchecked(ThrowingFn<T, R> f) {
    return t -> { try { return f.apply(t); }
                  catch (Exception e) { throw new RuntimeException(e); } };
}

• Callable is the JDK interface that allows checked exceptions.

The terminal operation propagates the exception and the pipeline stops; remaining elements are not processed (sequential case). Intermediate operations are lazy, so the exception surfaces at the terminal operation, not where the lambda is written.

• In parallel streams, one exception propagates to the caller and others may be lost or suppressed; side effects of other elements may or may not have occurred.
• No built-in per-element error handling; map to a result type (Either/Optional) when you need to continue.

The thread terminates; the exception is passed to the thread's UncaughtExceptionHandler (default prints the stack trace to stderr). Other threads, including main, keep running.

• If main throws, the JVM still waits for other non-daemon threads.
• The exception does not propagate to the thread that started it.

Lookup order: per-thread handler (setUncaughtExceptionHandler), then the thread group, then the global default (Thread.setDefaultUncaughtExceptionHandler).

• Use the default handler to log failures from any thread.
• It is invoked after the thread's run has been abandoned; it cannot resume the thread.
• Not triggered for exceptions captured in a Future.

execute(Runnable) lets the exception escape to the worker's uncaught handler. submit wraps the task in a FutureTask that captures the exception, surfacing it only when you call get() as ExecutionException.

• Fire-and-forget submit silently loses failures.
• ThreadPoolExecutor replaces a worker that died from execute.
• Override afterExecute or wrap tasks in logging for centralized handling.

For periodic tasks (scheduleAtFixedRate / WithFixedDelay) an uncaught exception cancels all subsequent executions, silently, because the failure is stored in the Future.

• Wrap the task body in try/catch (Throwable), log, and continue.
• Spring @Scheduled methods are wrapped and an error is logged, but later runs continue.

An exception in a stage completes it exceptionally and propagates to dependent stages, wrapped in CompletionException. Handle with exceptionally, handle or whenComplete.

• exceptionally(ex -> fallback) recovers; handle((v, ex) -> ...) sees both outcomes; whenComplete observes but does not change the result.
• join() throws CompletionException; get() throws ExecutionException.
• In exceptionally downstream of the source stage the exception is a CompletionException wrapper; the original is getCause().

final is a modifier (constant, non-overridable, non-subclassable). finally is the block that runs after try/catch. finalize() was an Object method called by GC before reclamation; it is deprecated for removal (Java 18+).

• Use try-with-resources or Cleaner instead of finalizers.
• Finalizers are unpredictable, slow GC and can resurrect objects.

Typical mistakes: log and rethrow (duplicate entries), e.printStackTrace(), logging e.getMessage() only, and passing the exception as a string concatenation so the stack trace is lost.

log.error("Failed to process order {}", id, e);   // good: last arg is Throwable
log.error("Failed: " + e);                        // bad: no stack trace

• Log once, at the boundary that handles the exception.
• Do not log sensitive data in messages (PII, tokens).
• With SLF4J, a trailing Throwable not matching a placeholder is printed as the stack trace.

An empty or log-less catch block hides failures, leaving the program in an unknown state and making debugging nearly impossible.

• If ignoring is intentional, comment why and name the variable ignored.
• Prefer handling, rethrowing with context, or failing fast.

Detect invalid state at the earliest point and throw immediately rather than propagating bad data. Validate arguments at method entry.

• Objects.requireNonNull(x, "x"), IllegalArgumentException, IllegalStateException.
• IllegalArgumentException: bad input. IllegalStateException: object is in the wrong state for the call.
• UnsupportedOperationException: operation not supported (e.g. immutable collection).

ClassNotFoundException is a checked exception from explicit loading (Class.forName, loadClass). NoClassDefFoundError is an Error thrown when a class present at compile time is missing at runtime, or its static init failed earlier.

• Typical cause: missing dependency in the runtime classpath, version conflicts, or failed static initializer.

assert cond : msg; throws AssertionError if the condition is false, but only when assertions are enabled with -ea. They are disabled by default.

• Use for internal invariants, never for validating public method arguments or anything with side effects.

Optional models an absent value without exceptions. orElseThrow(Supplier) converts absence into an exception at the point you choose.

User u = repo.findById(id)
    .orElseThrow(() -> new UserNotFoundException(id));

• Java 10 adds no-arg orElseThrow() throwing NoSuchElementException.
• Do not use Optional.get() blindly.

A snapshot of the call stack at construction (not at throw) time, as StackTraceElement[], with "Caused by" chains and "... n more" for frames shared with the enclosing trace.

• setStackTrace replaces it; getStackTrace returns a copy.
• JIT may omit stack traces for hot, frequently thrown built-in exceptions (-XX:-OmitStackTraceInFastThrow disables that).
• Stack trace depth is limited by -XX:MaxJavaStackTraceDepth.

Throw domain exceptions from services and translate them centrally with @RestControllerAdvice and @ExceptionHandler into a consistent error body and HTTP status.

@RestControllerAdvice
class ApiErrors {
    @ExceptionHandler(OrderNotFoundException.class)
    ResponseEntity<ProblemDetail> notFound(OrderNotFoundException e) {
        return ResponseEntity.status(404)
            .body(ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, e.getMessage()));
    }
}

• Keep controllers free of try/catch.
• Add a catch-all handler returning 500 with a generic message, logging the details with a correlation id.

A standard JSON error format (application/problem+json) with type, title, status, detail, instance and extension members. Spring 6 / Boot 3 provides ProblemDetail and ErrorResponse.

• Enable built-in handling for Spring MVC exceptions with spring.mvc.problemdetails.enabled=true.
• Or extend ResponseEntityExceptionHandler in your advice.
• Use setProperty to add custom fields such as error codes.

Client mistakes map to 4xx, server faults to 5xx.

• 400: malformed or invalid input (validation, MethodArgumentNotValidException).
• 401 / 403: unauthenticated / unauthorized.
• 404: resource not found. 409: state conflict (duplicate, optimistic lock).
• 422: semantically invalid payload (optional, team convention).
• 500: unexpected bug. 503: dependency down or overloaded.

DispatcherServlet delegates to HandlerExceptionResolvers in order: ExceptionHandlerExceptionResolver (@ExceptionHandler), ResponseStatusExceptionResolver (@ResponseStatus / ResponseStatusException), DefaultHandlerExceptionResolver (standard Spring exceptions).

• Controller-local @ExceptionHandler takes precedence over advice.
• The most specific exception type match wins.
• Unresolved exceptions go to the container error page (/error in Boot, BasicErrorController).

@Valid on @RequestBody throws MethodArgumentNotValidException (contains BindingResult); constraints on @RequestParam/@PathVariable with @Validated throw ConstraintViolationException (Boot 3 / Spring 6.1+ raises HandlerMethodValidationException for method validation).

• Map both to 400 and return field-level errors.
• Do not expose raw validation internals; map to field and message.

By default, a transaction rolls back on unchecked exceptions (RuntimeException and Error) and commits on checked exceptions.

• Override with rollbackFor = Exception.class or noRollbackFor.
• The exception must propagate out of the transactional proxy; if you catch it inside the method, the transaction commits.

With REQUIRED propagation, an inner @Transactional method that throws marks the shared transaction rollback-only; even if the outer method catches it, the commit fails with UnexpectedRollbackException.

• Use REQUIRES_NEW for work that must succeed or fail independently (separate connection).
• Or avoid throwing across the boundary and return a result.

Spring applies transactions through proxies. A call from within the same class bypasses the proxy, so no transactional advice runs, and rollback rules never apply. Private methods are not proxied.

• Fix by moving the method to another bean, injecting self, or using AspectJ mode.
• Also, the method must be public for default proxy-based advice.

JDBC throws checked SQLException with vendor codes; JPA throws unchecked PersistenceException subclasses. Spring translates both to the DataAccessException hierarchy (DuplicateKeyException, DataIntegrityViolationException, OptimisticLockingFailureException).

• Translation is applied to @Repository beans via a post processor.
• Services can catch Spring types without depending on the persistence technology.

getCause() returns only the immediate cause. To reach the root cause, loop until getCause() is null (guarding against cycles); Spring offers NestedExceptionUtils.getRootCause and Apache Commons has ExceptionUtils.getRootCause.

static Throwable root(Throwable t) {
    Throwable r = t;
    while (r.getCause() != null && r.getCause() != r) r = r.getCause();
    return r;
}

Retry only transient, idempotent failures, with a bounded attempt count, exponential backoff and jitter, and surface the final exception with earlier ones as suppressed.

• Spring Retry (@Retryable) or Resilience4j; combine with a circuit breaker to avoid hammering a failing dependency.
• Never retry validation errors or non-idempotent calls without idempotency keys.
• Retrying inside a @Transactional method retries within a rollback-only transaction; retry outside the transaction boundary.

Log fatal Errors and let the process die so an orchestrator restarts it, rather than continuing in an undefined state. For OOM, use -XX:+ExitOnOutOfMemoryError or -XX:+CrashOnOutOfMemoryError.

• A thread that hit OOM may have left locks or half-updated shared state.
• Catching Throwable in task loops is fine only if you rethrow VirtualMachineError and ThreadDeath-like fatals.

It prints 2. The return in finally replaces the value saved by the try block.

• The compiler accepts it (lint warning only).
• Same override happens for exceptions: finally { return 2; } swallows them.

ABCD. The catch returns, but finally still runs (C) before control goes back to the caller, which then prints D.

The caller gets IllegalArgumentException: finally. The IllegalStateException is lost completely; there is no cause and no suppressed link.

• Fix by catching in finally and addSuppressed, or by using try-with-resources.
• This is exactly why cleanup code in finally should not throw.

open 1
open 2
body
close 2
close 1

Resources are closed in reverse order of creation.

body 1 close. The body exception is primary; the close exception is added as suppressed.

F1 C:a F2. The inner finally runs while the exception unwinds, the outer catch handles it, then the outer finally runs.

No. NumberFormatException extends IllegalArgumentException, so the second catch is unreachable and javac reports "exception has already been caught". Put the subclass first.

The first access to Config throws ExceptionInInitializerError (cause: IllegalStateException). Every later access throws NoClassDefFoundError: Could not initialize class Config, whose trace hides the real cause.

• Look for the first occurrence in logs to find the root cause.
• Avoid risky work in static initializers; use lazy holders with explicit error handling.

Prints 1 and 2, then throws NumberFormatException for x; 4 is never processed. The pipeline is lazy and processed element by element, so earlier elements are already printed.

• To keep going, catch inside the mapper and return an Optional or result object, then filter.

submit captures the exception in the returned Future; no one calls get(), so it is never reported and the uncaught handler is not invoked.

• Use execute, or wrap the task body in try/catch with logging, or inspect Future.get().
• For centralized handling, subclass ThreadPoolExecutor and override afterExecute, which receives the Throwable for execute tasks and requires unwrapping the Future for submit.

An exception from a periodic task suppresses all subsequent executions, and it is stored silently in the ScheduledFuture. Wrap the body in try/catch(Exception) and log.

scheduler.scheduleAtFixedRate(() -> {
    try { process(); }
    catch (Exception e) { log.error("job failed", e); }
}, 0, 1, TimeUnit.MINUTES);

main done is printed and the stack trace for RuntimeException: t goes to stderr (order may vary). The JVM exits normally with code 0 since all non-daemon threads finished.

• Exit code 0 even though a thread failed; monitoring must not rely on it.

No. Spring rolls back by default only for RuntimeException and Error. The checked IOException propagates but the transaction commits, leaving the order marked paid.

• Fix: @Transactional(rollbackFor = IOException.class) or rollbackFor = Exception.class.

The inner call joined the outer transaction. When it threw, the proxy marked the shared transaction rollback-only. On exit, outer tries to commit and Spring throws UnexpectedRollbackException; the save is lost too.

• Fix with @Transactional(propagation = REQUIRES_NEW) on inner, or noRollbackFor, or make inner not throw.

place calls save on this, bypassing the Spring proxy, so no transaction is started and no rollback rule applies. With Spring Data's own repository transaction, repo.save has already committed.

• Fix: move save to another bean, put @Transactional on place, or use AspectJ weaving.

One failure produces three or more large stack traces, confusing triage and inflating logs. Log exactly once where the exception is finally handled (typically the global handler) and translate with the cause elsewhere.

• Lower layers add context via the message and cause, not by logging.

Jackson serializes Author.books, each Book.author points back to the author, repeating forever until the stack overflows. Lombok toString/hashCode on both sides cause the same effect.

• Return DTOs, or use @JsonManagedReference / @JsonBackReference, @JsonIgnore, or @JsonIdentityInfo.
• Exclude the back-reference from @ToString and @EqualsAndHashCode.

The JVM did not hit heap limits; the OS refused a new thread. Typical causes: unbounded thread creation (newCachedThreadPool, one thread per task), low ulimit -u, container pid limit, or too little native memory with a large -Xss.

• Take a thread dump to see who creates threads.
• Bound pools, use virtual threads (Java 21) for blocking I/O, reduce -Xss.
• Raising -Xmx makes it worse by leaving less native memory.

Each failure allocates an exception and fills its stack trace, which is costly especially under deep framework stacks. If most inputs are invalid, throughput drops by orders of magnitude versus a simple check.

• Pre-validate with a character loop or regex, or use a parser returning Optional/OptionalInt.
• When exceptions are necessary and frequent, create stackless ones (super(msg, null, false, false)).

After a hot code path throws the same implicit exception (NPE, ArithmeticException, ArrayIndexOutOfBounds, ClassCastException, ArrayStoreException) many times, C2 compiles the throw to reuse a preallocated exception without a stack trace (OmitStackTraceInFastThrow).

• Search earlier logs for the same exception, where the trace was still present.
• Disable with -XX:-OmitStackTraceInFastThrow.
• Fix the actual bug throwing so frequently.

shutdownNow() interrupts the thread; take() throws and clears the flag; the catch ignores it and the loop continues forever. Restore the flag and exit.

while (!Thread.currentThread().isInterrupted()) {
    try { run(queue.take()); }
    catch (InterruptedException e) { Thread.currentThread().interrupt(); }
}

Problems: single generic type (callers cannot react differently), checked (forces boilerplate through every layer), no cause constructor, no error code, vague message.

• Prefer a small hierarchy of unchecked exceptions (NotFoundException, ConflictException, ValidationException) deriving from one base with an error code.
• Add (String, Throwable) constructor and include relevant identifiers in the message.

Yes. Messages can leak SQL, table names, file paths, library versions or personal data, helping attackers. Return a generic message plus a correlation/trace id, and log the full details server side.

• Boot's default server.error.include-stacktrace=never and include-message=never exist for this reason.
• Validation errors are fine to detail because they describe client input.

The handler whose declared type is closest in the exception's class hierarchy wins, so nf handles OrderNotFoundException. Method order does not matter.

• A handler in the controller itself overrides global @ControllerAdvice handlers, even a less specific one.
• Multiple advice beans are ordered with @Order.

CompletionException:x. thenApply is skipped; the exception reaches exceptionally wrapped in a CompletionException since it passed through a dependent stage.

• If exceptionally were attached directly to supplyAsync, the argument is the raw IllegalStateException in many cases, but code should not depend on it; unwrap defensively.
• The output may appear after main ends, since it is async on the common pool (daemon threads).

One exception propagates from the terminal operation; which one is not deterministic. Other tasks may have run partially, and other exceptions are typically discarded (the fork-join framework may attach them).

• Do not rely on cleanup or ordering; collect errors explicitly (for example into a concurrent queue) when you need them all.

Only try is printed. System.exit halts the JVM (after shutdown hooks), so finally never runs.

• Same for Runtime.halt, a JVM crash, kill -9, or an infinite loop in try.

finally is printed, then RuntimeException: from catch propagates. The original IOException is not attached unless passed as a cause: new RuntimeException("from catch", e).

finally catch. The return value is computed, finally prints, then the method returns and println outputs the saved value.

No. An override cannot declare a checked exception broader than the overridden method; Exception is broader than IOException. throws FileNotFoundException, no throws, or throws RuntimeException would be fine.

Yes (Java 7+). The compiler knows the try body can throw only IOException (plus unchecked), and e is effectively final, so throw e is treated as throwing IOException.

• If you assign e = new Exception(); before throwing, it no longer compiles without throws Exception.

Only (1) compiles. (2) fails: alternatives are subclass-related. (3) fails because the multi-catch parameter is implicitly final.

• In (1) e has the static type Exception, so only members common to the alternatives are accessible without a cast.

Prints in with no exception: the generated code checks r != null before calling close().

open a
close a
caught init

Resources already initialized are closed when a later one fails; the body never runs. The catch runs after the close.

5 / 0 throws ArithmeticException: / by zero (execution stops). If it were skipped: 5.0 / 0 prints Infinity, 5 % 0 throws ArithmeticException, 0.0 / 0 prints NaN.

• Floating-point division never throws; integer division and remainder by zero do.

Prints [a, c] without exception. Removing the second-to-last element leaves size == cursor, so hasNext() returns false and next() (which checks modCount) is never called. Removing "a" or "c" would throw ConcurrentModificationException.

• Use Iterator.remove() or removeIf.

It throws IllegalStateException. orElse takes a value, so fail() is evaluated eagerly before the call even though the Optional is present. Use orElseGet(() -> fail()) or orElseThrow.

l.add(3) throws UnsupportedOperationException. Map.of("k", null) throws NullPointerException; the Java 9 factory methods reject nulls (List.of, Set.of, Map.of) and contains(null) also throws NPE.

• Arrays.asList supports set but not add/remove (also UnsupportedOperationException).

The call runs on another thread, so the caller cannot catch it. For void methods Spring passes the exception to an AsyncUncaughtExceptionHandler (by default it just logs at error level via SimpleAsyncUncaughtExceptionHandler).

• Return CompletableFuture<Void> to propagate failures to the caller.
• Configure a custom handler through AsyncConfigurer.getAsyncUncaughtExceptionHandler().

Prints created and nothing is thrown: intermediate operations are lazy and only run when a terminal operation executes. s.count() on Java 9+ may even skip map when size is computable, so no exception either; s.toList() would throw.

The new exception has no cause, so the original stack trace and type disappear. Pass it along: throw new ServiceException("Failed to read config", e);.

• Also avoid throw new RuntimeException(e.toString()) and e.printStackTrace().

When executeUpdate throws, close() calls are skipped and the connection is never returned to the pool. After a few failures the pool is exhausted.

try (Connection c = ds.getConnection();
     PreparedStatement ps = c.prepareStatement(sql)) {
    ps.executeUpdate();
}

Prints null. The object was allocated but the constructor did not complete, so the assignment never happens. If the constructor opened resources before failing, it must release them itself, as no one holds the reference to close.

• Partially constructed objects can leak this (for example registering listeners) before failing; avoid it.

After a persistence exception the transaction is typically rollback-only and the JPA session may be inconsistent, so retries in the same transaction fail or end with UnexpectedRollbackException. Retry must wrap the whole transactional unit, outside the proxy.

• Use Spring Retry with @Retryable on a bean that calls the transactional bean (aspect order: retry outside transaction).
• Retry only transient errors (deadlock, optimistic lock).

Use one consistent body for all failures (RFC 9457 ProblemDetail), stable machine-readable error codes, a correlation id, and mappings from exception types to statuses in one @RestControllerAdvice.

{
  "type": "https://api.example.com/errors/order-not-found",
  "title": "Order not found",
  "status": 404,
  "detail": "Order 42 does not exist",
  "code": "ORDER_NOT_FOUND",
  "traceId": "9f1c2a"
}

• Validation errors carry a list of {field, message}.
• Log 4xx at info/warn without stack traces, 5xx at error with stack traces.
• Do not leak internals; never change codes across versions without versioning.

audit.record joined the same transaction, so rollback erases the audit row. Annotate the audit method with @Transactional(propagation = REQUIRES_NEW) on a separate bean so it commits independently.

• Needs a second connection; watch pool size under load.
• Alternative: write audit events outside the DB (log, message queue) or use a transactional outbox.

get() wraps the task's exception in ExecutionException; the real one is getCause(), so this prints java.lang.NumberFormatException: For input string: "x".

• get() also throws InterruptedException (waiting thread interrupted) and CancellationException (task cancelled); get(timeout, unit) adds TimeoutException.

catch (Exception) also catches InterruptedException from call() and treats it as a retryable failure, ignoring cancellation. Also the original failure is lost in the final exception.

• Catch InterruptedException separately, restore the flag and stop.
• Keep the last exception as cause and earlier ones suppressed.

body close finally . Resources are closed before the optional catch and finally of the same statement.

It also catches OutOfMemoryError, StackOverflowError, LinkageError and InterruptedException. The loop may spin on an unrecoverable condition, log noisily or fail again while allocating, and ignore shutdown interrupts.

• Catch Exception, handle InterruptedException separately, and let VirtualMachineError terminate the process (use ExitOnOutOfMemoryError).

java.lang.IllegalStateException: load failed
java.io.IOException: disk
load failed

getMessage() is only the wrapper's message; the cause message is separate.

Each layer throws exceptions meaningful at its abstraction, preserving causes; only the outermost boundary maps them to protocol responses and logs.

• Repositories: Spring translates to DataAccessException; services convert to domain exceptions (OrderNotFoundException, InsufficientStockException).
• Controllers contain no try/catch; @RestControllerAdvice maps domain exceptions to ProblemDetail.
• Transactions: declare rollback rules for checked domain exceptions explicitly.
• Observability: log once with a trace id, metrics per exception type, alerts on 5xx.