Exception Handling Interview Questions

An exception is an unexpected event that interrupts normal program flow. Java creates an exception object containing its type, message, location, and call sequence.

Exception handling detects runtime problems and responds gracefully using try, catch, finally, throw, and throws.

It prevents sudden termination, provides useful messages, separates error handling from business logic, releases resources, and supports logging and monitoring.

Throwable is the root of Error and Exception. RuntimeException represents unchecked exceptions, while IOException, SQLException, and ClassNotFoundException are common checked exceptions.

Exceptions are usually application-level problems that may be recoverable. Errors normally indicate serious JVM or system failures such as OutOfMemoryError and should rarely be handled.

Checked exceptions are verified by the compiler. The caller must handle them with try-catch or declare them with throws. IOException and SQLException are examples.

Unchecked exceptions extend RuntimeException and are not enforced by the compiler. They commonly represent invalid input, programming errors, or invalid state.

Checked exceptions must be handled or declared and often represent external failures. Unchecked exceptions occur at runtime and commonly represent invalid code, input, or state.

A try block contains code that may throw an exception and must be followed by catch, finally, or both.

A catch block handles an exception thrown by its associated try block and can inspect methods such as getMessage, getCause, and printStackTrace.

finally contains cleanup code that normally runs whether the try succeeds or an exception is caught. Try-with-resources is preferred for closeable resources.

It normally executes, but not after System.exit, an unexpected JVM or operating-system termination, or a fatal process failure.

Yes. A try block may be followed by finally without catch. The exception is still propagated after cleanup.

No. Every catch block must be associated with a try block, otherwise the code does not compile.

Yes. Multiple catch blocks allow different exception types to receive different recovery messages or actions.

Specific exception types must appear before general types. A catch(Exception) before catch(IOException) makes the latter unreachable.

Multi-catch handles unrelated exception types in one catch block when their handling logic is identical. It was introduced in Java 7.

No. Multi-catch alternatives cannot have a parent-child relationship, such as IOException and FileNotFoundException. Use the parent type instead.

throw explicitly creates and raises one exception object, usually when input or a business rule is invalid.

throws declares checked exceptions that a method may pass to its caller. The caller must handle or further declare them.

throw raises an exception object inside code. throws declares exception types in a method signature and can list multiple types.

Exception propagation passes an unhandled exception up the method-call stack until a compatible handler is found or the JVM default handler terminates the thread.

Yes. Both can move through method calls. Checked exceptions must be handled or declared at required boundaries, while unchecked exceptions do not require declaration.

A custom exception is a domain-specific exception created to express a business or application failure clearly.

Extend Exception and declare or handle it at the call site.

Extend RuntimeException. The compiler does not force callers to handle or declare it.

Use them when a caller can reasonably recover from an external condition such as a missing file, failed network connection, or unavailable resource.

Use them for invalid arguments, violated business rules, missing entities, invalid application state, or failures that the current layer cannot meaningfully recover from.

Try-with-resources automatically closes resources implementing AutoCloseable or Closeable after the try block completes.

It reduces boilerplate, prevents resource leaks, closes resources reliably, and handles cleanup exceptions more safely than manual finally code.

Yes. Resources are closed automatically in reverse order of declaration.

AutoCloseable marks a resource that can be closed automatically. Its close method may throw Exception and is invoked by try-with-resources.

If the try body throws and close also throws, the body exception is primary and the close exception is attached as suppressed through getSuppressed().

The return from finally overrides the return from try. Returning from finally is bad practice because it can hide exceptions and results.

An exception from finally can hide an exception from try or catch. Cleanup code should avoid throwing unless there is no safe alternative.

Exception chaining wraps a low-level exception in a higher-level exception while preserving the original cause for debugging.

The cause preserves the original stack trace, root-cause details, and debugging context needed for production diagnosis.

A stack trace shows the exception type and the sequence of method calls, classes, files, and line numbers that led to the failure.

getMessage returns only the exception message. printStackTrace prints the complete call sequence and should normally be replaced by a logging framework in production.

It writes unstructured output directly to standard error, may bypass centralized logging, cannot be controlled by log level, and may expose sensitive details.

final prevents reassignment, overriding, or inheritance. finally provides cleanup flow. finalize is a deprecated cleanup callback and must not be used for resources.

Technically yes, but it also catches serious Errors such as OutOfMemoryError and StackOverflowError. Catch specific exceptions instead.

Technically yes, but catching Error does not guarantee safe recovery. Most Errors represent severe JVM or system failures.

It handles unrelated failures together, hides programming errors, weakens recovery decisions, and makes debugging harder. Catch specific types instead.

Exception swallowing is catching an exception without logging, handling, or rethrowing it. It makes failures invisible and should be avoided.

No. Validate predictable conditions normally and use exceptions for exceptional failures. Frequent exceptions create unnecessary stack traces and obscure intent.

It can throw the same checked exception, a narrower subclass, or none. It cannot throw a broader checked exception than the parent method.

Yes. Unchecked exceptions are not restricted by the checked-exception overriding rules.

Yes. A constructor can throw checked or unchecked exceptions. If it fails, the object is not created successfully.

It can throw unchecked exceptions. A failure during class initialization may be reported as ExceptionInInitializerError.

They can be handled locally, with @ExceptionHandler, globally with @RestControllerAdvice, or translated into custom structured API errors. Centralized handling is preferred for REST APIs.

@ExceptionHandler maps a specified exception to a handler method in a controller or controller advice class.

@ControllerAdvice centralizes shared controller behavior, including exception handlers, across multiple controllers.

@RestControllerAdvice combines controller advice with response-body behavior and is commonly used for global REST API exception handling.

Use a consistent object containing timestamp, status, safe error code, message, path, correlation ID, and validation field errors.

Throw a custom EmployeeNotFoundException from the service, handle it in global advice, and return a safe 404 response with a stable error code.

Handle MethodArgumentNotValidException in global advice, collect field errors, and return a structured 400 or 422 response.

Business exceptions represent known rule violations and usually map to 4xx responses. System exceptions represent technical failures and usually map to 5xx responses.

Generally no. Keep controllers focused on HTTP mapping and let global advice translate service and domain exceptions consistently.

400 represents invalid input, 401 authentication, 403 access denial, 404 missing resources, 409 conflicts, 429 rate limits, 500 unexpected errors, and 503 unavailable dependencies.

Return safe structured errors with status, business code, message, timestamp, path, and correlation ID. Keep stack traces and internal details in secured server logs.

Configure timeouts, classify client errors, retry only transient failures, use circuit breakers, preserve causes, log trace IDs, and avoid exposing downstream internals.

No. Retry transient timeouts or temporary unavailability with bounded exponential backoff. Do not retry validation, authentication, not-found, or non-idempotent failures without protection.

A correlation ID connects logs for one request across gateways, services, databases, Kafka, and downstream calls, making distributed failures traceable.

Classify transient and permanent failures, use bounded retry with backoff, dead-letter topics, idempotent processing, acknowledgements, and monitoring for retry and dead-letter counts.

A dead-letter topic stores messages that still fail after configured retries so the main consumer can continue and operators can investigate or replay them.

A poison-pill message repeatedly fails because of invalid data, schema, or deserialization. It should be isolated after bounded retries instead of blocking the consumer forever.

Translate persistence failures into meaningful application exceptions, log safe context, propagate to global handling, and never expose SQL, credentials, schema details, or vendor messages.

Spring translates vendor-specific database failures into a consistent DataAccessException hierarchy, such as DuplicateKeyException and DataIntegrityViolationException.

By default, Spring rolls back for RuntimeException and Error but not for checked exceptions.

Use @Transactional(rollbackFor = IOException.class) or another explicitly configured exception type.

If a runtime exception is caught and swallowed, Spring may commit the transaction. Rethrow it or explicitly mark rollback when failure should undo the work.

Throw a custom unchecked exception in the service, map it globally, and return a safe 404 Not Found response.

Enforce a database unique constraint, translate DataIntegrityViolationException, and return 409 Conflict. A pre-check alone is unsafe under concurrency.

Configure timeouts, retry safely with backoff, use a circuit breaker, preserve the cause, log correlation details, and return a safe service-unavailable response.

Catch failures at the job boundary, log job and execution IDs, record metrics, isolate item failures when appropriate, retry transient work, and notify support for critical failures.

Observe CompletableFuture or reactive failures with exceptionally, handle, or an equivalent error path. Do not allow asynchronous failures to disappear silently.

Repositories handle persistence details, services enforce business rules, controllers remain thin, global advice maps errors to responses, and logging/monitoring captures technical context.

The exception propagates to the caller. If nobody handles it, the JVM default handler prints details and terminates the affected thread.

The new exception propagates unless another surrounding try-catch handles it. The original handler does not automatically handle failures created inside itself.

Yes, multi-catch can handle unrelated exception types in one block when their handling logic is the same.

Yes. A handler can log and rethrow the same exception or wrap it in a higher-level exception while preserving the cause.

Yes, but it is optional because the compiler does not require unchecked exceptions to be declared. It may still document the method contract.

Yes. An unhandled exception declared by main reaches the JVM default handler and normally terminates the application.

Yes, but excessive nesting makes control flow hard to understand. Prefer focused methods and specific handlers.

Catch specific exceptions, avoid empty catches, preserve causes, use custom domain errors, prefer try-with-resources, avoid finally returns, log safely, centralize REST handling, and distinguish retryable failures.

Usually not at every layer. Add context when wrapping and log once at the boundary that has enough business and technical context.

Include exception and stack trace, correlation and trace IDs, operation, safe business identifiers, downstream service, retry count, and duration. Never log credentials, tokens, or unmasked sensitive data.

Do not return stack traces, SQL, class names, file paths, internal addresses, credentials, tokens, or raw downstream errors. Return a safe structured error instead.