When to Catch and When to Throw — Generated by AI

The Trap of Checked Exceptions: When to Catch and When to Throw in Java

Mastering checked exceptions without driving yourself crazy

In this article, we’ll tackle one of Java’s most debated features: checked exceptions. If you’ve ever stared at a method throwing five different exceptions and wondered whether to catch them all or just add throws Exception to your signature, you’re not alone. Let’s cut through the noise and build a practical decision framework.

You can read this article for free by clicking ***here***.

Table of Contents

1. The Checked Exception Problem
2. When to Catch: The Recovery Rule
3. When to Throw: The Abstraction Leak
4. The Middle Ground: Wrapping and Translating
5. Real-World Patterns That Work

The Checked Exception Problem

Checked exceptions force you to handle potential failures at compile time. Sounds great in theory—until you’re maintaining a codebase where every method throws Exception because someone got tired of dealing with it.

// What we often end up with
public void saveUser(User user) throws Exception {
    // implementation
}

This defeats the entire purpose. The compiler can’t help you if everything is Exception. The real question isn’t “should I use checked exceptions?”—it’s “when should I catch, and when should I throw?”

Let’s look at the fundamental issue. Java’s creators thought forcing developers to handle errors would produce more reliable code. What actually happens in practice is that developers either:

• Swallow exceptions with empty catch blocks
• Add throws Exception to every method signature
• Wrap everything in RuntimeException subclasses

None of these are good. But there’s a better way.

When to Catch: The Recovery Rule

Catch an exception only when you can actually do something meaningful about it. This sounds obvious, but look at how many catch blocks just log and rethrow:

try {
    processPayment(order);
} catch (PaymentException e) {
    log.error("Payment failed", e);
    throw e;  // Why did we catch this?
}

If you’re just logging and rethrowing, don’t catch at all. Let the caller deal with it. Catch only when you can:

• Retry the operation (network timeout)
• Use a fallback value (cache miss)
• Return a default result (configuration missing)
• Transform the exception (abstraction boundary)

Here’s a practical example:

public User getUserById(Long userId) {
    try {
        return userRepository.findById(userId);
    } catch (DataAccessException e) {
        // We can recover - return a stale cached version
        User cachedUser = cacheManager.get(userId);
        if (cachedUser != null) {
            log.warn("Returning cached user due to DB failure", e);
            return cachedUser;
        }
        // Can't recover - let it propagate
        throw new UserServiceException("Unable to fetch user", e);
    }
}

Notice we handled the recoverable case and transformed the exception for the unrecoverable one. The caller of getUserById doesn’t care about DataAccessException—they care about user service failures.

When to Throw: The Abstraction Leak

Here’s where most developers get it wrong. They let implementation details leak through their exception signatures.

// Bad - leaks implementation
public void saveReport(Report report) throws SQLException, FileNotFoundException, 
    IOException, ParseException {
    // Database save
    // File write
    // XML parsing
}

Your callers shouldn’t know you’re using a database or writing files. That’s your problem, not theirs. Instead, throw exceptions that make sense at your abstraction level:

// Better - abstracts implementation details
public void saveReport(Report report) throws ReportStorageException {
    try {
        // Database save
        // File write
        // XML parsing
    } catch (SQLException | IOException | ParseException e) {
        throw new ReportStorageException("Failed to save report", e);
    }
}

Now the caller only needs to handle ReportStorageException. If you change your implementation to use a cloud service instead of a database, the exception signature doesn’t change.

The Middle Ground: Wrapping and Translating

Sometimes you need to cross abstraction boundaries. This is where exception translation patterns shine. Let’s create a clean service layer:

@Service
public class OrderService {
    private final OrderRepository repository;
    private final PaymentGateway gateway;

    public Order createOrder(OrderRequest request) throws OrderProcessingException {
        try {
            validateRequest(request);
            PaymentResult payment = gateway.charge(request.getAmount());
            return repository.save(new Order(request, payment));
        } catch (ValidationException e) {
            // Business rule violation - don't wrap, rethrow
            throw e;
        } catch (PaymentException e) {
            // Wrap in service-level exception
            throw new OrderProcessingException("Payment failed", e, ErrorCode.PAYMENT_FAILED);
        } catch (DataAccessException e) {
            // Wrap infrastructure exception
            throw new OrderProcessingException("Database error", e, ErrorCode.STORAGE_ERROR);
        }
    }
}

Notice the pattern: validation exceptions pass through unchanged (they’re already at the right abstraction level), while infrastructure exceptions get wrapped. The caller only needs to handle OrderProcessingException and ValidationException.

Real-World Patterns That Work

Let’s look at some patterns that actually work in production code.

Pattern 1: The Result Type

Instead of throwing exceptions for expected failures, return a result type:

public class Result<T> {
    private final T value;
    private final String error;

    private Result(T value, String error) {
        this.value = value;
        this.error = error;
    }

    public static <T> Result<T> success(T value) {
        return new Result<>(value, null);
    }

    public static <T> Result<T> failure(String error) {
        return new Result<>(null, error);
    }

    public boolean isSuccess() { return error == null; }
    public T getValue() { return value; }
    public String getError() { return error; }
}

// Usage
public Result<User> findUser(String email) {
    if (email == null || email.isBlank()) {
        return Result.failure("Email cannot be empty");
    }
    return Result.success(new User(email));
}

This works great for expected failure modes like validation errors. Save exceptions for truly exceptional situations.

Pattern 2: The Boundary Catcher

Catch at system boundaries, not in the middle:

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(OrderProcessingException.class)
    public ResponseEntity<ErrorResponse> handleOrderProcessing(OrderProcessingException e) {
        ErrorResponse response = new ErrorResponse(
            e.getErrorCode().getHttpStatus(),
            e.getMessage()
        );
        return ResponseEntity.status(response.status()).body(response);
    }

    @ExceptionHandler(ValidationException.class)
    public ResponseEntity<ErrorResponse> handleValidation(ValidationException e) {
        return ResponseEntity.badRequest()
            .body(new ErrorResponse(400, e.getMessage()));
    }
}

Catch at the boundary (REST controller, message listener, batch job) and translate to the appropriate response format. Everything between boundaries should just throw.

Pattern 3: The Unchecked Wrapper

For frameworks that don’t play well with checked exceptions (looking at you, lambda streams):

@FunctionalInterface
public interface CheckedFunction<T, R> {
    R apply(T t) throws Exception;
}

public static <T, R> Function<T, R> unchecked(CheckedFunction<T, R> fn) {
    return t -> {
        try {
            return fn.apply(t);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    };
}

// Usage
List<String> ids = users.stream()
    .map(unchecked(user -> externalService.fetchData(user.getId())))
    .collect(Collectors.toList());

Use this sparingly. It’s a workaround, not a solution.

The Bottom Line

Here’s your decision tree for every exception you encounter:

1. Can you recover? Catch it, handle it, move on. 2. Is it at the right abstraction level? Let it propagate.
2. Is it leaking implementation details? Wrap it in an appropriate exception.
3. Is it an expected failure? Consider a Result type instead. 5. Are you at a system boundary? Catch and translate to the output format.

That’s it. Five questions. If you follow this, your code will be cleaner, your callers will thank you, and you’ll stop seeing throws Exception everywhere.

Java’s checked exceptions aren’t inherently bad — they’re just a tool that’s easy to misuse. Use them for recoverable conditions at the right abstraction level, and wrap everything else. Your future self will thank you when you’re not debugging a catch block that swallowed a critical error.

Read more about exceptions from our publication here.

Tags: java, exceptions, checked-exceptions, software-engineering, clean-code, spring-boot

References:

• [Oracle Java Tutorials: Exceptions]
• [Effective Java, 3rd Edition — Item 73: Throw exceptions appropriate to the abstraction]
• [Spring Boot Error Handling Guide]

To support my work, please follow and clap.