Jump into concepts and practice - no test required
or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Custom error response models in FastAPI
📖 Scenario: You are building a simple API that returns user information. You want to handle errors clearly by sending custom error messages in a structured way.
🎯 Goal: Create a FastAPI app that returns user data for a given user ID. If the user ID is not found, return a custom error response model with a clear message and error code.
📋 What You'll Learn
Create a dictionary called users with user IDs as keys and names as values.
Create a Pydantic model called ErrorResponse with fields error_code (int) and message (str).
Create a GET endpoint /users/{user_id} that returns the user name if found.
If the user ID is not found, return a JSON response using the ErrorResponse model with error_code 404 and a message User not found.
💡 Why This Matters
🌍 Real World
APIs often need to send clear error messages to clients. Custom error response models help keep error data consistent and easy to understand.
💼 Career
Backend developers use FastAPI and Pydantic to build APIs with clear error handling, improving user experience and debugging.
Progress0 / 4 steps
1
Create the initial user data dictionary
Create a dictionary called users with these exact entries: 1: "Alice", 2: "Bob", 3: "Charlie".
FastAPI
Hint
Use curly braces to create a dictionary with keys 1, 2, 3 and values "Alice", "Bob", "Charlie".
2
Define the custom error response model
Import BaseModel from pydantic and create a class called ErrorResponse that inherits from BaseModel. It should have two fields: error_code of type int and message of type str.
FastAPI
Hint
Use class ErrorResponse(BaseModel): and define the two fields with type annotations.
3
Create the FastAPI app and GET endpoint
Import FastAPI and HTTPException from fastapi. Create a FastAPI app called app. Define a GET endpoint /users/{user_id} that takes user_id as an int path parameter. If user_id is in users, return a dictionary with key name and the user name as value.
FastAPI
Hint
Use @app.get("/users/{user_id}") decorator and an async function with user_id: int parameter.
4
Return custom error response when user not found
In the get_user function, if user_id is not in users, raise HTTPException with status_code=404 and detail set to an instance of ErrorResponse with error_code=404 and message="User not found".
FastAPI
Hint
Use raise HTTPException(status_code=404, detail=ErrorResponse(error_code=404, message="User not found").dict()) to send the custom error response.
Practice
(1/5)
1. What is the main purpose of using custom error response models in FastAPI?
easy
A. To define a clear and consistent structure for error messages returned by the API
B. To speed up the API response time
C. To automatically fix errors in the API code
D. To hide all error messages from the client
Solution
Step 1: Understand error response models
Custom error response models define how error messages look, making them clear and consistent.
Step 2: Identify the purpose in FastAPI
FastAPI uses these models to send structured error info to clients, improving API usability.
Final Answer:
To define a clear and consistent structure for error messages returned by the API -> Option A
Pydantic models are defined as classes inheriting from BaseModel with typed attributes.
Step 2: Match correct syntax
class ErrorResponse(BaseModel): message: str; code: int correctly defines a class with typed fields using BaseModel.
Final Answer:
class ErrorResponse(BaseModel): message: str; code: int -> Option B
Quick Check:
Pydantic model = class with BaseModel [OK]
Hint: Use class with BaseModel and typed fields [OK]
Common Mistakes:
Defining models as functions
Using plain dictionaries instead of classes
Missing BaseModel inheritance
3. Given this FastAPI code snippet, what will be the response when a ValueError is raised?
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
from pydantic import BaseModel
app = FastAPI()
class ErrorResponse(BaseModel):
detail: str
@app.exception_handler(ValueError)
async def value_error_handler(request: Request, exc: ValueError):
return JSONResponse(
status_code=400,
content=ErrorResponse(detail=str(exc)).dict()
)
@app.get("/test")
async def test():
raise ValueError("Invalid input")
medium
A. Empty response with status 204
B. Plain text 'Invalid input' with status 500
C. {"detail": "Invalid input"} with status 400
D. JSON with key 'error' and message 'Invalid input' with status 400
Solution
Step 1: Understand exception handler behavior
The handler catches ValueError and returns JSONResponse with ErrorResponse model content and status 400.
Step 2: Check response content and status
The content is the dict form of ErrorResponse with detail set to the exception message, so JSON has key 'detail' with 'Invalid input'.
Final Answer:
{"detail": "Invalid input"} with status 400 -> Option C
Quick Check:
Exception handler returns JSON with detail key [OK]
Hint: Exception handler returns model dict as JSON with status [OK]
Common Mistakes:
Expecting plain text instead of JSON
Confusing status codes
Assuming different JSON key names
4. Identify the error in this FastAPI custom error handler code:
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
from pydantic import BaseModel
app = FastAPI()
class ErrorResponse(BaseModel):
message: str
@app.exception_handler(KeyError)
async def key_error_handler(request: Request, exc: KeyError):
return JSONResponse(
status_code=404,
content=ErrorResponse(message=exc).dict()
)
medium
A. Missing BaseModel inheritance in ErrorResponse
B. Exception handler must be synchronous, not async
C. Using status code 404 instead of 400
D. Passing the exception object directly instead of converting to string
Solution
Step 1: Check how exception is passed to model
The code passes exc (KeyError object) directly to message field which expects a string.
Step 2: Identify correct usage
It should convert exc to string with str(exc) to avoid type errors.
Final Answer:
Passing the exception object directly instead of converting to string -> Option D
Quick Check:
Exception message must be string [OK]
Hint: Convert exception to string before passing to model [OK]
Common Mistakes:
Passing exception object without str()
Confusing async/sync handler rules
Incorrect status code choice
5. You want to create a FastAPI app that returns a custom error response with fields error_code (int) and error_msg (str) whenever a RuntimeError occurs. Which of the following code snippets correctly implements this behavior?
hard
A. class CustomError(BaseModel): error_code: int; error_msg: str
@app.exception_handler(RuntimeError)
async def runtime_error_handler(request: Request, exc: RuntimeError):
return JSONResponse(status_code=500, content=CustomError(error_code=1001, error_msg=str(exc)).dict())
B. class CustomError(BaseModel): error_code: str; error_msg: int
@app.exception_handler(RuntimeError)
async def runtime_error_handler(request: Request, exc: RuntimeError):
return JSONResponse(status_code=400, content=CustomError(error_code='1001', error_msg=exc).dict())
class CustomError(BaseModel): error_code: int; error_msg: str
@app.exception_handler(RuntimeError)
async def runtime_error_handler(request: Request, exc: RuntimeError):
return JSONResponse(status_code=500, content=CustomError(error_code=1001, error_msg=str(exc)).dict()) defines CustomError inheriting from BaseModel with correct field types (int and str).
Step 2: Implement exception handler properly
class CustomError(BaseModel): error_code: int; error_msg: str
@app.exception_handler(RuntimeError)
async def runtime_error_handler(request: Request, exc: RuntimeError):
return JSONResponse(status_code=500, content=CustomError(error_code=1001, error_msg=str(exc)).dict())'s handler returns JSONResponse with status 500 and content as dict from CustomError instance, converting exception to string.
Step 3: Check other options for errors
class CustomError(BaseModel): error_code: str; error_msg: int
@app.exception_handler(RuntimeError)
async def runtime_error_handler(request: Request, exc: RuntimeError):
return JSONResponse(status_code=400, content=CustomError(error_code='1001', error_msg=exc).dict()) swaps types incorrectly and passes exc without str(); class CustomError:
def __init__(self, error_code, error_msg):
self.error_code = error_code
self.error_msg = error_msg
@app.exception_handler(RuntimeError)
async def runtime_error_handler(request: Request, exc: RuntimeError):
return JSONResponse(status_code=500, content=CustomError(1001, str(exc))) uses plain class not BaseModel and returns object not dict; @app.exception_handler(RuntimeError)
async def runtime_error_handler(request: Request, exc: RuntimeError):
return JSONResponse(status_code=500, content={'error_code': 1001, 'error_msg': str(exc)}) skips model usage.
Final Answer:
Option A correctly defines model and handler returning proper JSON response -> Option A
Quick Check:
Use BaseModel with typed fields and dict() in handler [OK]
Hint: Use BaseModel and dict() for error response content [OK]