Throws

🔍 What Is It?

throws declaration:

public void readConfig(String path) throws IOException, ParseException {
    // may throw IOException (file not found)
    // may throw ParseException (invalid format)
}

Rules:

• →Only required for checked exceptions (extends Exception but not RuntimeException)
• →Unchecked exceptions (RuntimeException subclasses) do not require throws declaration
• →A method can declare throws for more exceptions than it actually throws (for future-proofing or documentation)
• →Overriding methods cannot add new checked exceptions not declared in the parent

throw vs throws:

• →throw — statement that throws an exception
• →throws — method signature declaration

Checked Exception Design Intent:

James Gosling (Java creator) intended checked exceptions for recoverable conditions: "If you call this method, you must think about what to do when the file isn't there." In practice, this led to massive boilerplate.

🎯 Why Do We Need It?

Checked exceptions serve as documentation:

• →They tell callers: "this method can fail in these specific ways"
• →The compiler enforces that callers acknowledge these failure modes
• →Forces developers to think about error handling at the API design level

However, checked exceptions have significant drawbacks:

• →Boilerplate in every caller
• →Cannot use in lambdas without wrapping
• →Forces implementation details into the API
• →Often leads to empty catch blocks (swallowing exceptions)

🏗️ What Happens in Real Projects?

In enterprise code, you'll encounter checked exceptions mainly at I/O boundaries:

// Standard library methods with checked exceptions
Files.readAllBytes(path)        // throws IOException
Class.forName("com.Example")   // throws ClassNotFoundException
new URL("http://...")           // throws MalformedURLException

// Modern frameworks wrap these in unchecked exceptions
// Spring's JdbcTemplate wraps SQLException in DataAccessException (unchecked)
// This is why you don't see throws SQLException in Spring code

⚙️ How It Works

Checked Exception Propagation:

methodA() throws IOException
    calls methodB() throws IOException
        calls methodC() throws IOException
            calls Files.readAllBytes()  // source of IOException

Every method in the chain must either handle or declare the exception.

Wrapping checked exceptions in unchecked:

try {
    return Files.readAllBytes(path);
} catch (IOException e) {
    throw new RuntimeException("Failed to read file: " + path, e);
}

Sneaky throws (advanced):

Using generics to throw checked exceptions without declaring them — used by Lombok's @SneakyThrows.

💻 Example

Checked Exceptions and Modern Alternatives — How to handle checked exceptions in modern Java and when to wrap them.

// Traditional checked exception handling
public class FileProcessor {
    
    // Option 1: Declare throws — push decision to caller
    public String readConfig(Path path) throws IOException {
        return Files.readString(path);
    }
    
    // Option 2: Catch and wrap as unchecked — hide implementation detail
    public String readConfigSafe(Path path) {
        try {
            return Files.readString(path);
        } catch (IOException e) {
            throw new ConfigurationException("Cannot read config: " + path, e);
        }
    }
    
    // Option 3: Return Optional — for "file might not exist" cases
    public Optional<String> tryReadConfig(Path path) {
        try {
            return Optional.of(Files.readString(path));
        } catch (IOException e) {
            log.warn("Config file not found: {}", path);
            return Optional.empty();
        }
    }
}

// Checked exceptions in lambdas — the problem
List<Path> paths = List.of(Path.of("a.txt"), Path.of("b.txt"));

// DOES NOT COMPILE: Files.readString throws checked IOException
// paths.stream().map(Files::readString).collect(Collectors.toList());

// Solution 1: Wrap in a helper
@FunctionalInterface
interface ThrowingFunction<T, R> {
    R apply(T t) throws Exception;
    
    static <T, R> Function<T, R> wrap(ThrowingFunction<T, R> f) {
        return t -> {
            try { return f.apply(t); }
            catch (Exception e) { throw new RuntimeException(e); }
        };
    }
}

List<String> contents = paths.stream()
    .map(ThrowingFunction.wrap(Files::readString))
    .collect(Collectors.toList());

// Solution 2: Lombok @SneakyThrows
@SneakyThrows  // throws IOException without declaring it
public String readWithLombok(Path path) {
    return Files.readString(path);
}

🤔 Common Confusions

🚨 Common Production Issues

✅ Best Practices

🏛️ Architect's Note

💬 Frequently Asked Questions

🎯 Key Takeaways

🔗 Related Topics

🎯 Practice this topic in interviews

↗ Where this topic fits