yoklainterview sim
ProgressHistory

Backend Java Exceptions Interview Questions

75 verified Backend Java Exceptions interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Java ExceptionsDifficulty 1
Which of these four standard classes is a checked exception in Java?
  • aNullPointerException, because dereferencing null is a common enough mistake that the compiler forces you to handle it
  • bIOException, because it extends Exception directly rather than RuntimeException, so it is checked✓
  • cArithmeticException, because dividing by zero is always detectable at compile time and therefore checked
  • dIllegalStateException, because it signals a serious programming error that must always be declared or caught
Explanation:A checked exception is any subclass of Exception that does NOT extend RuntimeException. IOException extends Exception directly, so it is checked and must be declared with throws or caught. NullPointerException, ArithmeticException and IllegalStateException all extend RuntimeException, so they are unchecked and the compiler never forces you to handle them.
Java ExceptionsDifficulty 2
class Res implements AutoCloseable {
    private final String name;
    Res(String name) {
        this.name = name;
        if (name.equals("B")) {
            throw new RuntimeException("cannot open " + name);
        }
        System.out.println("open " + name);
    }
    public void close() { System.out.println("close " + name); }
}

public class Main {
    public static void main(String[] args) {
        try (Res a = new Res("A"); Res b = new Res("B")) {
            System.out.println("body");
        } catch (RuntimeException e) {
            System.out.println("caught: " + e.getMessage());
        }
    }
}

What is printed?
  • aopen A, caught: cannot open B — resource A is never closed because its constructor already ran but the try body never started
  • bopen A, close A, caught: cannot open B — the JVM tracks that resource A was already successfully constructed and closes it even though resource B's constructor failed and the try body never ran✓
  • cNothing is printed and the JVM terminates abnormally, because a failing constructor inside a try-with-resources header leaves the resource list in an undefined state
  • dopen A, open B, close A, caught: cannot open B — B's constructor runs to completion before any resource is validated, and only the first resource gets closed afterward
Explanation:try-with-resources closes exactly the resources that were successfully constructed before the failure, in reverse order — it does not require the try body to have started. Here a is fully constructed ("open A" prints), then constructing b throws before it is assigned, so b was never a resource to close. The statement still closes a ("close A") as it unwinds, and the RuntimeException then propagates to the catch clause.
Java ExceptionsDifficulty 2
public class Main {
    static int test() {
        try {
            return 1;
        } finally {
            return 2;
        }
    }
    public static void main(String[] args) {
        System.out.println(test());
    }
}

What is printed?
  • a2, because the return statement inside finally discards the pending return value from try and becomes the method's actual result✓
  • b1, because the try block's return value is already committed before finally runs and cannot be replaced
  • cThe code fails to compile, because a return statement is not allowed inside a finally block
  • d0, because returning from both try and finally cancels the return altogether and the method falls through to the implicit default value for its declared return type
Explanation:A return inside finally swallows any pending return (or thrown exception) from the try/catch block and becomes the method's actual outcome. Here try schedules a return of 1, but before that value is handed back, finally runs and returns 2 instead — so test() returns 2. This is a well-known finally trap and is legal Java, not a compile error.
Java ExceptionsDifficulty 3
public class Main {
    static void inner() {
        try {
            throw new RuntimeException("boom");
        } finally {
            System.out.println("inner-finally");
        }
    }
    public static void main(String[] args) {
        try {
            inner();
        } catch (RuntimeException e) {
            System.out.println("caught: " + e.getMessage());
        }
    }
}

What is printed?
  • acaught: boom — the finally block never runs because the exception is thrown and caught in a different method
  • binner-finally — execution stops after the finally block runs, so the exception never reaches main
  • cinner-finally, caught: boom — finally runs first as the exception propagates, then the caller catches it✓
  • dcaught: boom, inner-finally — the exception is caught first, and finally runs afterward as a cleanup step
Explanation:When an exception is thrown inside try, finally runs BEFORE the exception continues propagating up the call stack, even though finally itself doesn't catch anything. So inner-finally prints first as the stack unwinds out of inner(), and only then does the exception reach main's catch block, printing caught: boom.
Java ExceptionsDifficulty 2
try {
    Files.readAllBytes(Path.of("data.txt"));
    Integer.parseInt("x");
} catch (IOException | NumberFormatException e) {
    e = new NumberFormatException("replaced");
    System.out.println(e.getMessage());
}

What is true about this multi-catch block?
  • aIt compiles and runs correctly, because a multi-catch parameter can be reassigned like any normal local variable
  • bIt fails to compile, because a multi-catch parameter e is implicitly final and cannot be reassigned inside the catch block✓
  • cIt fails to compile, because IOException and NumberFormatException cannot appear together in the same multi-catch clause, regardless of their position in the exception hierarchy
  • dIt compiles, but reassigning e silently has no effect and the original caught exception's message is printed instead
Explanation:A multi-catch parameter (catch (A | B e)) is implicitly final, so e = new NumberFormatException(...) is a compile error. This restriction doesn't apply to a single-type catch parameter, which can be reassigned. Combining unrelated exception types like IOException and NumberFormatException in one multi-catch clause is perfectly legal as long as neither is a subtype of the other.
Java ExceptionsDifficulty 1
A method calls another method that declares throws IOException, and the calling method does not catch it. What must the calling method do for the code to compile?
  • aNothing special is required, because IOException is unchecked and the compiler never verifies its handling
  • bIt must wrap the call in a try block with an empty catch clause, since Java requires every checked call site to have one
  • cIt must catch IOException specifically; declaring it with throws on the calling method's own signature is never accepted as a valid alternative by the compiler
  • dIt must either catch IOException or declare throws IOException on its own signature, propagating the obligation to its caller✓
Explanation:IOException is a checked exception, so the compiler enforces the "catch or specify" rule: any method that can let it escape must either handle it in a try/catch or declare it with throws IOException in its own signature, which simply pushes the same obligation onto whoever calls that method next.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview