Exception Design & Serialization Edge Cases — Interview Questions

How to use this lesson

Intermediate exception questions are about design choices and failure modes you've debugged. "Have you ever…?" questions invite a short real-world story: the situation, what went wrong, and what you changed. Keep one or two ready.

Q1. Can static fields be serialized?

Short answer: No. Serialization captures instance state, and static fields belong to the class. On deserialization, a static field simply has whatever value the class currently holds in the receiving JVM.

Key points to cover:

• The one "static" value that does matter is serialVersionUID. It's a private static final field that the serialization mechanism reads specially, to check version compatibility.

Q2. Are static fields serialized? (Asked again: prove it)

Short answer: No. Here's a quick demonstration:

class Config implements Serializable {
    static String region = "ap-south-1";
    String name = "orders";
}
// serialize a Config, then set Config.region = "us-east-1", then deserialize:
// restored.name → "orders" (instance state restored)
// Config.region → "us-east-1" (the CURRENT static value; nothing was restored)

If static state must travel with an object, copy it into an instance field, or handle it in custom writeObject/readObject hooks.

Q3. What happens if an exception is thrown during serialization?

Short answer: writeObject aborts, and the exception propagates to the caller:

• NotSerializableException for a non-serializable object in the graph;
• InvalidClassException for class problems;
• a plain IOException for stream or disk failures;
• anything your custom writeObject throws.

The stream is left partially written and unusable. Treat the output as corrupt, and don't try to resume.

Key points to cover:

• Write to a temporary file, then atomically rename it on success, so a failure never leaves a half-written file where readers expect a good one.
• ObjectOutputStream isn't transactional. Serialize into memory first (ByteArrayOutputStream) if you need all-or-nothing behaviour.

Q4. A Serializable class has a member that isn't serializable. What happens, and how do you fix it?

Short answer: Serialization throws java.io.NotSerializableException, naming the offending class. The fixes are:

1. Make the member's class Serializable, if you own it.
2. Mark the field transient (and rebuild it after deserialization, lazily or in readObject).
3. Use custom writeObject/readObject to save a serializable representation (for example, save a connection's URL instead of the connection itself).
4. Use a serialization proxy (writeReplace/readResolve).

public class ReportJob implements Serializable {
    private final String reportId;
    private transient DataSource dataSource;            // not serializable: re-acquired after load

    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
        in.defaultReadObject();
        this.dataSource = DataSourceRegistry.lookup("reports");
    }
}

Key points to cover:

• transient fields come back as null, 0 or false. Every piece of code that uses them must cope with that, or rebuild them.

Q5. What's the difference between NoClassDefFoundError and ClassNotFoundException?

Short answer:

Common trap: saying "ClassNotFoundException means the class existed at compile time". Dynamic loading by name involves no compile-time reference at all. That describes NoClassDefFoundError.

Q6. What happens when an exception is thrown in a static initialiser?

Short answer: The first attempt to initialise the class throws ExceptionInInitializerError, wrapping the cause. The class is then marked as erroneous. Every later use throws NoClassDefFoundError ("Could not initialize class X"), with no stack trace of the original cause in older JDKs (newer JDKs link the original exception).

Key points to cover:

• Debugging tip: the first error in the logs has the real root cause. The later NoClassDefFoundErrors are just echoes.
• Avoid risky work (I/O, network calls, parsing configuration) in static initialisers. Use lazy initialisation, or dependency injection.

Q7. When would you deliberately choose a checked exception over an unchecked one?

Short answer: When the failure is expected, recoverable, and the caller can reasonably do something about it, so the compiler should force the caller to decide.

• A file-import API that throws ImportFormatException, so the caller can show the user which row is wrong.
• A payment client that throws PaymentDeclinedException, so the caller must choose between retrying with another card and cancelling the order.

Use unchecked exceptions for programming errors and violated preconditions (IllegalArgumentException, IllegalStateException), and for failures the immediate caller can't handle.

Key points to cover:

• Many modern codebases (Spring included) lean towards unchecked exceptions, because checked exceptions don't compose well with lambdas and streams, and they tend to leak implementation details up through layers. Whichever you choose, apply it consistently at module boundaries.

Q8. Have you used a finally block? Describe a scenario.

Short answer: Typical real uses are guaranteed cleanup that isn't an AutoCloseable:

• releasing a ReentrantLock (lock.unlock() in finally);
• restoring the thread's state in a pool (MDC.clear(), threadLocal.remove());
• resetting a flag or metrics timer;
• releasing a semaphore permit.

For resources that implement AutoCloseable, use try-with-resources instead.

MDC.put("orderId", orderId);
try {
    processOrder(orderId);
} finally {
    MDC.remove("orderId");        // otherwise the next task on this pooled thread logs the wrong orderId
}

Q9. Has a finally block ever caused unexpected behaviour?

Short answer: The common surprises:

• An exception thrown in finally masks the original exception from try. For example, close() fails and hides the real error. try-with-resources fixes this by attaching close failures as suppressed exceptions.
• return in finally swallows exceptions and overrides the return value.
• Slow or blocking cleanup in finally delays error propagation.
• Code in finally runs even on the error path, where objects may be partially initialised, which can cause NPEs.

try (var in = Files.newInputStream(path)) {
    parse(in);
} catch (IOException e) {
    for (Throwable s : e.getSuppressed()) log.warn("close failed too", s);   // not lost
    throw e;
}

Q10. Why is catching Throwable bad practice?

Short answer: Throwable includes Errors: OutOfMemoryError, StackOverflowError and LinkageError. After one of those, the JVM or application may be in an inconsistent state. Catching and continuing hides fatal conditions, can corrupt data, and keeps a sick instance serving traffic instead of letting it crash and restart. It also catches ThreadDeath, and interferes with frameworks that rely on errors propagating.

Key points to cover:

• Acceptable exceptions: top-level safety nets at thread or task boundaries (thread pools, schedulers, message listeners), where you log and rethrow, or report and terminate. Never catch it just to swallow it.
• Catch the narrowest exception types you can actually handle.

Follow-up questions this topic invites — and their answers

Q: What are suppressed exceptions? A: When an exception is already propagating and another one occurs during cleanup (such as close() in try-with-resources), the second is attached to the first with addSuppressed, rather than replacing it. Retrieve them with getSuppressed().

Q: Should you log and rethrow an exception? A: Usually not both at every layer, because you'd log the same error many times. Log once, at the boundary that handles it (a controller advice, or a message-listener error handler), and wrap with context when rethrowing.

Q: How do you design a custom exception hierarchy? A: A small base exception per module (OrderException extends RuntimeException), with specific subclasses for the cases callers handle differently. Include context fields (order ID, error code), and always keep the cause.

Q: Does Java 21 change exception handling? A: Not fundamentally. Structured concurrency (preview in 21) propagates subtask failures to the parent scope, and sealed result types plus pattern matching make "error as a value" styles more practical alongside exceptions.