Exception handling in async in Spring Boot - Step-by-Step Execution

Concept Flow - Exception handling in async

Start Async Method

↓

Execute Async Task

↓

Exception Occurs?

No→Complete Normally

Yes↓

Catch Exception

↓

Handle Exception (log, notify, fallback)

↓

Complete Async Task

This flow shows how an asynchronous method runs, checks for exceptions, catches them if any, handles them, and then completes.

Execution Sample

Spring Boot

import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;

@Service
public class AsyncService {

  @Async
  public void runAsync() {
    try {
      Thread.sleep(1000);
      throw new RuntimeException("Error in async");
    } catch (Exception e) {
      System.out.println("Caught: " + e.getMessage());
    }
  }
}

This code runs a method asynchronously, waits 1 second, throws an exception, catches it, and prints a message.

Execution Table

Step	Action	Exception Thrown?	Exception Caught?	Output
1	Start async method runAsync()	No	No	No output yet
2	Thread.sleep(1000) executes	No	No	Pauses 1 second
3	RuntimeException thrown	Yes	No	Exception thrown
4	Catch block catches exception	Yes	Yes	Prints: Caught: Error in async
5	Async method completes	No	No	Method ends

💡 Async method ends after exception is caught and handled.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Exception	null	null	RuntimeException("Error in async")	Caught RuntimeException	null

Key Moments - 2 Insights

Why doesn't the exception crash the whole application?

Because the exception is caught inside the async method's try-catch block (see execution_table step 4), it is handled locally and does not propagate.

What happens if we don't catch exceptions in async methods?

Uncaught exceptions in async methods may be lost or logged by Spring's async executor but won't crash the main thread. Handling them explicitly is best practice.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the exception caught?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'Exception Caught?' column in the execution_table.

According to variable_tracker, what is the state of the Exception variable after step 4?

A Caught RuntimeException

B null

C RuntimeException("Error in async")

D Undefined

💡 Hint

Look at the Exception variable value in variable_tracker after Step 4.

If the try-catch block was removed, what would happen to the exception?

A It would crash the main application thread immediately.

B It would be caught automatically by Spring and logged.

C It would be ignored silently with no output.

D It would propagate to the caller synchronously.

💡 Hint

Recall how Spring handles uncaught exceptions in async methods as per key_moments.

Concept Snapshot

Exception handling in async methods:
- Use try-catch inside @Async methods
- Catch exceptions to prevent silent failures
- Handle exceptions by logging or fallback
- Uncaught exceptions are logged by Spring but don't crash main thread
- Always handle exceptions for reliable async behavior

Full Transcript

In Spring Boot, asynchronous methods marked with @Async run in separate threads. When exceptions occur inside these methods, they do not crash the main application thread. Instead, if you use a try-catch block inside the async method, you can catch and handle exceptions locally. This prevents silent failures and allows you to log or respond to errors properly. If exceptions are not caught, Spring logs them but the main thread continues running. This example shows an async method that sleeps for one second, throws a RuntimeException, catches it, and prints a message. The execution table traces each step: starting the method, sleeping, throwing the exception, catching it, and completing. The variable tracker shows the exception variable changing from null to the thrown exception and then being caught. Key moments clarify why catching exceptions prevents crashes and what happens if you don't catch them. The visual quiz tests understanding of when exceptions are caught and how Spring handles uncaught exceptions. Remember to always handle exceptions inside async methods for safe and predictable behavior.

Practice

1. What is the main purpose of using AsyncUncaughtExceptionHandler in Spring Boot asynchronous methods?

easy

A. To handle exceptions thrown by async methods that return void

B. To automatically retry failed async methods

C. To log successful completion of async methods

D. To convert async methods into synchronous ones

Solution

1. Step 1: Understand async method return types

   Async methods returning void cannot return exceptions directly to the caller.

2. Step 2: Role of AsyncUncaughtExceptionHandler

   This handler catches exceptions from void async methods to prevent app crashes.

3. Final Answer:

   To handle exceptions thrown by async methods that return void -> Option A

4. Quick Check:

   Void async exceptions need AsyncUncaughtExceptionHandler [OK]

Hint: Void async methods need special exception handler [OK]

Common Mistakes:

• Thinking AsyncUncaughtExceptionHandler retries failed tasks
• Assuming it handles exceptions for Future-returning methods
• Confusing it with synchronous exception handling

2. Which of the following is the correct way to declare an async method that returns a result and handles exceptions properly?

easy

A. @Async public void processData() throws Exception { ... }

B. @Async public Future<String> fetchData() throws InterruptedException { return null; }

C. @Async public String fetchData() { return "data"; }

D. @Async public CompletableFuture<String> fetchData() { return CompletableFuture.completedFuture("data"); }

Solution

1. Step 1: Identify async method return types

   Async methods returning results should return Future or CompletableFuture to handle async results and exceptions.

2. Step 2: Check method signatures

   @Async public CompletableFuture<String> fetchData() { return CompletableFuture.completedFuture("data"); } returns CompletableFuture<String> correctly and does not declare checked exceptions, which is proper for async methods.

3. Final Answer:

   @Async public CompletableFuture<String> fetchData() { return CompletableFuture.completedFuture("data"); } -> Option D

4. Quick Check:

   Async methods with results use CompletableFuture [OK]

Hint: Async methods with results return CompletableFuture or Future [OK]

Common Mistakes:

• Declaring async methods with void when result is needed
• Throwing checked exceptions directly in async methods
• Returning raw types instead of Future or CompletableFuture

3. Given the following async method, what will be the output if an exception occurs inside the CompletableFuture?

medium

A. The exception is caught inside exceptionally and a fallback value is returned

B. The exception is automatically logged and the method returns null

C. The exception crashes the application immediately

D. The exception is ignored and the method returns normally

Solution

1. Step 1: Analyze CompletableFuture exception handling

   The exceptionally method handles exceptions and provides fallback values.

2. Step 2: Understand method behavior on exception

   If an exception occurs, exceptionally returns the fallback value instead of propagating the exception.

3. Final Answer:

   The exception is caught inside exceptionally and a fallback value is returned -> Option A

4. Quick Check:

   CompletableFuture.exceptionally handles exceptions [OK]

Hint: Use exceptionally to catch async exceptions with fallback [OK]

Common Mistakes:

• Assuming exceptions crash the app without handling
• Expecting null return instead of fallback value
• Ignoring the need for exceptionally or handle methods

4. Identify the error in this async method that uses Future and explain why exceptions are not handled properly:

@Async
public Future<String> loadData() {
  throw new RuntimeException("Failed");
}

medium

A. Future cannot be used with @Async methods

B. Method should not be annotated with @Async when returning Future

C. Throwing exception directly in async method causes it to be lost; should return Future with exception

D. RuntimeException must be caught inside the method before throwing

Solution

1. Step 1: Understand async method exception handling

   Exceptions thrown directly in async methods returning Future are not propagated properly.

2. Step 2: Proper way to handle exceptions in Future

   Return a Future that completes exceptionally instead of throwing directly.

3. Final Answer:

   Throwing exception directly in async method causes it to be lost; should return Future with exception -> Option C

4. Quick Check:

   Throwing exceptions directly in async Future methods is incorrect [OK]

Hint: Return Future with exception, don't throw directly in async methods [OK]

Common Mistakes:

• Throwing exceptions directly in async methods returning Future
• Ignoring exception handling in async methods
• Misusing @Async annotation with incompatible return types

5. You have an async method returning CompletableFuture<String> that may throw exceptions. How can you combine exception handling and fallback logic so the caller always gets a valid string without blocking?

hard

A. Use get() on CompletableFuture and catch exceptions synchronously

B. Use handle method on CompletableFuture to catch exceptions and provide fallback value

C. Wrap the async method call in a try-catch block in the caller thread

D. Declare the async method to throw checked exceptions and let caller handle them

Solution

1. Step 1: Understand async exception handling with CompletableFuture

   The handle method allows processing both result and exception without blocking.

2. Step 2: Implement fallback logic in handle

   Inside handle, check if exception is present and return fallback string if so.

3. Final Answer:

   Use handle method on CompletableFuture to catch exceptions and provide fallback value -> Option B

4. Quick Check:

   CompletableFuture.handle combines result and exception handling [OK]

Hint: Use CompletableFuture.handle for async fallback without blocking [OK]

Common Mistakes:

• Blocking caller thread with get() defeats async purpose
• Trying to catch exceptions outside async context
• Declaring checked exceptions in async methods unnecessarily