Java Interview Questions

Home / All Answers / Exceptions

Question 22 · Section 7

Can you throw a checked exception from a method without throws?

Normally no - Java compiler won't allow it. But there are ways to bypass this.

English Exceptions Source Markdown
Language versions: English Russian Ukrainian

Junior Level

Short answer

Normally no - Java compiler won’t allow it. But there are ways to bypass this.

Standard behavior

// Won't compile - IOException not declared in throws
public void readFile() {
    throw new IOException("Error"); // Compilation error: Unhandled exception
}

// Correct - declare throws
public void readFile() throws IOException {
    throw new IOException("Error");
}

Exception: RuntimeException

Unchecked exceptions can be thrown without throws:

public void fail() {
    throw new RuntimeException("Error"); // Compiles without throws
}

Wrapping in RuntimeException

The simplest and safest way to “throw” a checked exception without throws:

public void readFile() { // No throws!
    try {
        Files.readAllLines(Paths.get("file.txt"));
    } catch (IOException e) {
        throw new RuntimeException("Failed to read file", e); // Wrap it
    }
}

Middle Level

Technique 1: Generic Hack (Type Erasure) - step by step

Using type erasure to deceive the compiler:

public class Sneaky {
    public static void main(String[] args) {
        throwSneaky(new IOException("Surprise!")); // Compiles without throws!
    }

    @SuppressWarnings("unchecked")
    private static <E extends Throwable> void throwSneaky(Throwable e) throws E {
        throw (E) e;
    }
}

Step-by-step type erasure mechanism:

  1. Declaration: <E extends Throwable> void throwSneaky(Throwable e) throws E - compiler sees generic type E with upper bound Throwable.

  2. Call: throwSneaky(new IOException(...)) - compiler tries to infer E. The argument has type Throwable, so E remains at Throwable level.

  3. Cast (E) e: at compile time the cast looks safe - e has type Throwable, and E extends Throwable. The compiler cannot check that the real type of e is IOException, because generic information is erased.

  4. Erasure: at compilation E is replaced with upper bound Throwable. The bytecode signature becomes: throws Throwable. But JVM doesn’t check checked exceptions at runtime - this is purely a compiler check.

  5. Result: throw (Throwable) e passes compilation, and at runtime the original IOException is thrown. The throws E check in signature after erasure doesn’t restrict the exception type, because Throwable is the upper bound.

Key insight: checked/unchecked checking is static compiler analysis, not a runtime mechanism. JVM doesn’t distinguish checked and unchecked when throwing an exception. Bytecode for throw new IOException() and throw new RuntimeException() is identical - the athrow instruction.

Technique 2: Lombok @SneakyThrows

@SneakyThrows
public void readFile() {
    // IOException without throws!
    Files.readAllLines(Paths.get("file.txt"));
}

This is the de facto standard in modern projects. Does the same thing as Generic Hack.

Technique 3: Unsafe.throwException()

import sun.misc.Unsafe;

// Low-level way
unsafe.throwException(new IOException("Direct throw"));

Throws directly, ignoring any compiler checks.

Why you need this

1. Lambda expressions:

// Won't compile
list.stream().map(path -> Files.readString(path))

// With sneaky throws - works
list.stream().map(path -> sneakyRead(path))

2. Third-party library interfaces:

public class MyRunnable implements Runnable {
    @SneakyThrows
    public void run() {
        // Working with I/O without try-catch
        Files.readAllLines(Paths.get("data.txt"));
    }
}

Senior Level

Contract violation

The calling code expects the method to be safe (since there’s no throws). If it gets an IOException - it cannot catch it via catch (IOException e):

try {
    sneakyMethod();
} catch (Exception e) { // Have to catch general Exception
    // Unclear what exactly happened
}

No Overhead

Unlike wrapping in RuntimeException, Sneaky Throws don’t create a wrapper object in the heap. This is a “free” throw from a resource perspective.

Bytecode Inspection

In the bytecode of a method with @SneakyThrows - regular athrow instruction. The magic is only in the compiler’s head.

Thread Health

If a thread “dies” from an unexpected checked exception, UncaughtExceptionHandler will still catch it - works with the base Throwable.

Dangers

  • Debugging difficulty - stack trace is correct, but error handling logic is unpredictable
  • Violation of the principle of least surprise - other developers don’t expect this behavior
  • Don’t use in business logic - only in infrastructure code

When NOT to use sneaky throws

  1. Business logic - violates method contract, caller doesn’t know about exceptions
  2. Public library APIs - clients won’t be able to properly handle the error via catch (SpecificException e)
  3. Team development - code review should block such tricks, they violate the principle of least surprise
  4. Production code without UncaughtExceptionHandler - unexpected checked exception will kill the thread without warning
  5. Instead of wrapping in RuntimeException - always prefer explicit wrapper if the caller can meaningfully handle the error
  6. When caller and callee are from different teams - without contract coordination, sneaky throws create hidden dependencies

Caveat: Java 21+ and future versions

Starting from Java 21, Project Amber and other error handling improvement initiatives may affect sneaky throws behavior. Although as of Java 21 the technique continues to work, keep an eye on:

  • JEP 443 (Unnamed Patterns and Variables) - doesn’t directly affect, but shows the direction of code simplification
  • Future JEPs on exception handling - possible compiler changes that will tighten or loosen rules
  • Lombok compatibility - @SneakyThrows may need updating for new JDK versions

At the moment (Java 21) the technique works, but in new projects explicit wrappers or @SneakyThrows from Lombok (which is easy to remove if changes occur) are preferable.

Diagnostics

  • javap -c - you’ll see regular athrow instruction
  • Static Analysis - Sonar may warn about sneaky throws
  • UncaughtExceptionHandler - catches all exceptions, including sneaky

Interview Cheat Sheet

Must know:

  • Standard answer: no - compiler won’t allow throwing checked exception without throws
  • Wrapping in RuntimeException - safest way to bypass the limitation
  • Generic Hack (type erasure): <E extends Throwable> void throwSneaky(Throwable e) throws E { throw (E) e; } - checked by compiler, but not JVM
  • Lombok @SneakyThrows - de facto standard, does the same as generic hack
  • Checked/unchecked checking - static compiler analysis, JVM doesn’t distinguish them on athrow
  • Sneaky throws violates contract - caller cannot catch (SpecificException e)
  • Don’t use in business logic and public APIs - only infrastructure code

Frequent follow-up questions:

  • Why does Generic Hack work? - Type erasure replaces E with Throwable, JVM doesn’t check checked at runtime
  • What are the dangers of sneaky throws? - Caller doesn’t know about exceptions, cannot handle properly
  • What’s better - wrapper or sneaky? - Wrapper is always preferable, sneaky - only for lambdas/interfaces
  • Does it work in Java 21+? - Yes, but watch for changes in future JEPs on exception handling

Red flags (NOT to say):

  • “I use sneaky throws in business logic” - violates principle of least surprise
  • “I throw checked without throws and RuntimeException” - only via unsafe tricks
  • “Sneaky throws creates overhead” - on the contrary, doesn’t create wrapper object
  • “Compiler and JVM check checked the same way” - no, JVM doesn’t check, only compiler

Related topics:

  • [[20. What does the throws keyword do]] - standard exception declaration mechanism
  • [[18. What is exception wrapping (wrapping)]] - wrapping as alternative
  • [[3. What is an unchecked exception (Runtime Exception)]] - unchecked don’t require throws
  • [[27. Can you rethrow an exception]] - rethrow and sneaky throws