Custom exception classes in Spring Boot - Step-by-Step Execution

Concept Flow - Custom exception classes

Define custom exception class

↓

Throw custom exception in code

↓

Catch custom exception in handler

↓

Return error response or handle

↓

End

This flow shows how you create a custom exception, throw it in your code, catch it in a handler, and then respond or handle the error.

Execution Sample

Spring Boot

public class MyException extends RuntimeException {
  public MyException(String message) {
    super(message);
  }
}

throw new MyException("Error happened");

Defines a custom exception class and throws it with a message.

Execution Table

Step	Action	Code Line	Result
1	Define class MyException extending RuntimeException	public class MyException extends RuntimeException {...}	Class MyException created
2	Call constructor with message "Error happened"	new MyException("Error happened")	MyException instance created with message
3	Throw MyException	throw new MyException("Error happened")	Exception thrown, program flow interrupted
4	Catch MyException in handler	catch (MyException e) {...}	Exception caught, message available
5	Handle exception (e.g., return error response)	return ResponseEntity.status(400).body(e.getMessage());	Client receives error message

💡 Exception thrown and caught, error handled, program continues or ends gracefully

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
exceptionInstance	null	MyException("Error happened")	Thrown	Caught with message "Error happened"	Handled

Key Moments - 3 Insights

Why do we extend RuntimeException instead of Exception?

Extending RuntimeException makes the exception unchecked, so you don't have to declare it in method signatures. See Step 1 and Step 3 in execution_table.

What happens when the exception is thrown?

The program flow stops at the throw statement and looks for a matching catch block. See Step 3 and Step 4 in execution_table.

How do we access the error message from the exception?

Using e.getMessage() inside the catch block returns the message passed when creating the exception. See Step 4 and Step 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of exceptionInstance after Step 2?

A It is null

B It is a MyException object with message "Error happened"

C It is a RuntimeException without message

D It is already caught

💡 Hint

Check the variable_tracker row for exceptionInstance after Step 2

At which step does the program flow stop due to the exception being thrown?

A Step 1

B Step 2

C Step 3

D Step 5

💡 Hint

Look at the execution_table action and result columns for Step 3

If we did not catch the custom exception, what would happen?

A The program would crash or return an error response automatically

B The exception would be ignored

C The program would continue normally

D The exception would be converted to a warning

💡 Hint

Think about what happens when an exception is thrown but not caught (refer to Step 4 and Step 5)

Concept Snapshot

Custom exceptions in Spring Boot:
- Create by extending RuntimeException
- Add constructors to pass messages
- Throw with 'throw new MyException(message)'
- Catch in @ControllerAdvice or try-catch
- Use getMessage() to get error details
- Helps handle errors clearly and specifically

Full Transcript

In Spring Boot, you create custom exception classes by extending RuntimeException. This lets you throw your own errors with messages. When you throw the exception, the program stops normal flow and looks for a catch block. In the catch block, you can handle the error, for example by returning a response with the error message. This process helps you manage errors clearly and give users helpful feedback. The execution table shows each step: defining the class, creating an instance, throwing it, catching it, and handling it. The variable tracker shows how the exception instance changes from null to thrown and caught. Key moments include why to extend RuntimeException, what happens when throwing, and how to get the message. The quiz tests understanding of these steps and states.

Practice

1. What is the main purpose of creating a custom exception class in Spring Boot?

easy

A. To automatically fix errors without any code changes

B. To replace all built-in exceptions with your own versions

C. To make the application run faster by skipping error checks

D. To handle specific error cases clearly and separately in your application

Solution

1. Step 1: Understand the role of custom exceptions

   Custom exceptions help you identify and manage specific error situations clearly in your code.

2. Step 2: Compare with other options

   Replacing all exceptions or auto-fixing errors is not the goal; custom exceptions improve clarity and control.

3. Final Answer:

   To handle specific error cases clearly and separately in your application -> Option D

4. Quick Check:

   Custom exceptions clarify error handling = C [OK]

Hint: Custom exceptions clarify specific errors clearly [OK]

Common Mistakes:

• Thinking custom exceptions replace all errors
• Believing they fix errors automatically
• Assuming they improve performance directly

2. Which of the following is the correct way to declare a custom exception class in Spring Boot?

easy

A. public class MyException extends RuntimeException { public MyException(String message) { super(message); } }

B. public interface MyException extends RuntimeException {}

C. public class MyException implements RuntimeException {}

D. public class MyException extends Exception {}

Solution

1. Step 1: Check correct inheritance

   Custom exceptions usually extend RuntimeException to avoid mandatory try-catch blocks.

2. Step 2: Verify constructor usage

   Providing a constructor that calls super(message) is standard to pass error messages.

3. Final Answer:

   public class MyException extends RuntimeException { public MyException(String message) { super(message); } } -> Option A

4. Quick Check:

   Extend RuntimeException with constructor = D [OK]

Hint: Extend RuntimeException and add constructor with message [OK]

Common Mistakes:

• Using implements instead of extends
• Extending Exception instead of RuntimeException
• Declaring interface instead of class

3. Given this custom exception class:

public class DataNotFoundException extends RuntimeException {
  public DataNotFoundException(String message) {
    super(message);
  }
}

What will happen if this exception is thrown in a Spring Boot controller without any handler?

medium

A. The exception will be ignored and the request will succeed

B. The application will return a 500 Internal Server Error response

C. The application will automatically return a 404 Not Found response

D. The server will crash and stop running

Solution

1. Step 1: Understand default Spring Boot behavior

   Without a handler, Spring Boot treats RuntimeExceptions as server errors and returns HTTP 500.

2. Step 2: Check other options

   Ignoring exceptions or auto 404 responses require explicit handling; server crash does not happen.

3. Final Answer:

   The application will return a 500 Internal Server Error response -> Option B

4. Quick Check:

   Unhandled RuntimeException = HTTP 500 error [OK]

Hint: Unhandled RuntimeException returns HTTP 500 by default [OK]

Common Mistakes:

• Assuming automatic 404 response
• Thinking exceptions are ignored
• Believing server crashes on exception

4. Identify the error in this custom exception class:

public class InvalidInputException extends RuntimeException {
  public InvalidInputException() {
    super();
  }
  public void InvalidInputException(String message) {
    super(message);
  }
}

medium

A. The class should extend Exception, not RuntimeException

B. The first constructor should accept a message parameter

C. The second method should be a constructor but is declared as void

D. There is no error; the class is correct

Solution

1. Step 1: Check method declarations

   The second method has a return type void, so it is not a constructor but a normal method.

2. Step 2: Understand constructor syntax

   Constructors must not have a return type; this causes the message constructor to be invalid.

3. Final Answer:

   The second method should be a constructor but is declared as void -> Option C

4. Quick Check:

   Constructor must not have return type = B [OK]

Hint: Constructors have no return type, not even void [OK]

Common Mistakes:

• Adding void to constructor
• Confusing methods with constructors
• Extending wrong exception class

5. How can you handle a custom exception ResourceMissingException globally in Spring Boot to return a 404 status with a custom message?

hard

A. Create a @ControllerAdvice class with a method annotated @ExceptionHandler(ResourceMissingException.class) that returns ResponseEntity with status 404 and message

B. Throw ResourceMissingException inside a try-catch block and catch it in every controller method separately

C. Override the default error page in Spring Boot without using @ExceptionHandler

D. Use @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) on the exception class

Solution

1. Step 1: Use @ControllerAdvice for global handling

   This annotation allows centralized exception handling across all controllers.

2. Step 2: Define @ExceptionHandler method for ResourceMissingException

   This method can build a ResponseEntity with HTTP 404 and a custom message to send back.

3. Final Answer:

   Create a @ControllerAdvice class with a method annotated @ExceptionHandler(ResourceMissingException.class) that returns ResponseEntity with status 404 and message -> Option A

4. Quick Check:

   Global handler with @ExceptionHandler = A [OK]

Hint: Use @ControllerAdvice and @ExceptionHandler for global exception handling [OK]

Common Mistakes:

• Catching exceptions in every controller method
• Using wrong HTTP status annotation
• Overriding error page without exception handler