Bird
Raised Fist0
FastAPIframework~8 mins

Global exception middleware in FastAPI - Performance & Optimization

Choose your learning style10 modes available

Start learning this pattern below

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
Performance: Global exception middleware
MEDIUM IMPACT
This affects server response time and user experience by handling errors centrally without repeating code.
Handling errors in a FastAPI app
FastAPI
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse

app = FastAPI()

@app.middleware("http")
async def global_exception_handler(request: Request, call_next):
    try:
        response = await call_next(request)
        return response
    except Exception as exc:
        return JSONResponse(status_code=500, content={"detail": "Internal Server Error"})

@app.get("/items/{item_id}")
async def read_item(item_id: int):
    if item_id == 0:
        raise ValueError("Invalid item id")
    return {"item_id": item_id}
Centralizes error handling, reduces repeated code, and ensures consistent error responses with minimal overhead.
📈 Performance GainSaves development time and reduces response inconsistencies; no extra reflows or blocking on client side.
Handling errors in a FastAPI app
FastAPI
from fastapi import FastAPI, HTTPException
app = FastAPI()

@app.get("/items/{item_id}")
async def read_item(item_id: int):
    if item_id == 0:
        raise HTTPException(status_code=404, detail="Item not found")
    return {"item_id": item_id}
Errors are handled individually in each route, causing repeated code and inconsistent error responses.
📉 Performance CostIncreases code size and complexity, causing minor delays in development and potential inconsistent error handling.
Performance Comparison
PatternDOM OperationsReflowsPaint CostVerdict
Per-route error handlingN/A (server-side)N/AN/A[!] OK
Global exception middlewareN/A (server-side)N/AN/A[OK] Good
Rendering Pipeline
Global exception middleware runs on the server before sending the response, catching errors to prevent server crashes and send consistent error messages.
Server Processing
Response Generation
⚠️ BottleneckException handling logic can add slight delay if complex but usually minimal.
Core Web Vital Affected
INP
This affects server response time and user experience by handling errors centrally without repeating code.
Optimization Tips
1Use global exception middleware to centralize error handling.
2Keep exception middleware logic simple to avoid server delays.
3Consistent error responses improve user experience and debugging.
Performance Quiz - 3 Questions
Test your performance knowledge
What is a main performance benefit of using global exception middleware in FastAPI?
AReduces duplicated error handling code and ensures consistent responses
BImproves client-side rendering speed
CDecreases CSS paint time
DEliminates all server errors
DevTools: Network
How to check: Open DevTools, go to Network tab, make a request that triggers an error, and inspect the response status and body.
What to look for: Consistent error status codes and JSON error messages indicate good global error handling.

Practice

(1/5)
1. What is the main purpose of global exception middleware in a FastAPI application?
easy
A. To automatically generate API documentation
B. To speed up the API response time by caching results
C. To manage database connections efficiently
D. To catch and handle errors for the entire application in one place

Solution

  1. Step 1: Understand middleware role

    Middleware runs for every request and can intercept errors globally.
  2. Step 2: Identify purpose of global exception middleware

    It catches errors from any part of the app and handles them centrally.
  3. Final Answer:

    To catch and handle errors for the entire application in one place -> Option D
  4. Quick Check:

    Global error handling = catch all errors [OK]
Hint: Global middleware handles all errors in one place [OK]
Common Mistakes:
  • Confusing middleware with caching or documentation
  • Thinking it manages database connections
  • Assuming it only handles specific routes
2. Which of the following is the correct way to add a global exception middleware in FastAPI?
easy
A. app.use_middleware(ExceptionMiddleware, handler=custom_handler)
B. app.add_middleware(ExceptionMiddleware, handler=custom_handler)
C. app.middleware(ExceptionMiddleware, handler=custom_handler)
D. app.register_middleware(ExceptionMiddleware, handler=custom_handler)

Solution

  1. Step 1: Recall FastAPI middleware syntax

    FastAPI uses add_middleware method to add middleware.
  2. Step 2: Match correct method name

    Only add_middleware is valid; others are incorrect method names.
  3. Final Answer:

    app.add_middleware(ExceptionMiddleware, handler=custom_handler) -> Option B
  4. Quick Check:

    Use add_middleware() to add middleware [OK]
Hint: Use add_middleware() method to add middleware [OK]
Common Mistakes:
  • Using incorrect method names like use_middleware or register_middleware
  • Confusing middleware with route decorators
  • Missing required parameters in add_middleware
3. Given this FastAPI middleware code snippet, what will be the response if a ValueError is raised inside a route?
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse

app = FastAPI()

@app.middleware("http")
async def catch_exceptions_middleware(request: Request, call_next):
    try:
        response = await call_next(request)
        return response
    except ValueError as e:
        return JSONResponse(status_code=400, content={"error": str(e)})

@app.get("/test")
async def test_route():
    raise ValueError("Invalid input")
medium
A. {"detail": "ValueError"} with status 422
B. 500 Internal Server Error with default HTML page
C. {"error": "Invalid input"} with status 400
D. Empty response with status 200

Solution

  1. Step 1: Analyze middleware error handling

    The middleware catches ValueError and returns JSONResponse with status 400 and error message.
  2. Step 2: Check route behavior

    The route raises ValueError("Invalid input"), triggering the middleware's except block.
  3. Final Answer:

    {"error": "Invalid input"} with status 400 -> Option C
  4. Quick Check:

    Middleware catches ValueError and returns JSON error [OK]
Hint: Middleware catches ValueError and returns JSON with status 400 [OK]
Common Mistakes:
  • Assuming default 500 error instead of custom JSON response
  • Confusing status codes 422 and 400
  • Ignoring middleware and expecting normal route error
4. Identify the error in this FastAPI global exception middleware code:
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse

app = FastAPI()

@app.middleware("http")
async def exception_middleware(request: Request, call_next):
    try:
        response = call_next(request)
        return response
    except Exception as e:
        return JSONResponse(status_code=500, content={"error": "Server error"})
medium
A. Missing await before call_next(request)
B. Incorrect exception type used
C. JSONResponse should not be returned in middleware
D. Middleware should not catch exceptions

Solution

  1. Step 1: Check async call to call_next

    call_next is an async function and must be awaited.
  2. Step 2: Identify missing await

    Code calls call_next(request) without await, causing a coroutine object to be returned instead of response.
  3. Final Answer:

    Missing await before call_next(request) -> Option A
  4. Quick Check:

    Always await async call_next() in middleware [OK]
Hint: Always await call_next(request) in async middleware [OK]
Common Mistakes:
  • Forgetting to await async call_next
  • Thinking JSONResponse can't be returned in middleware
  • Believing middleware shouldn't catch exceptions
5. You want to create a global exception middleware in FastAPI that logs all exceptions and returns a JSON error with status 500. Which code snippet correctly implements this behavior?
hard
A. @app.middleware('http') async def global_exception(request, call_next): try: return await call_next(request) except Exception as e: print(f"Error: {e}") return JSONResponse(status_code=500, content={"error": "Internal server error"})
B. app.add_middleware(ExceptionMiddleware, handler=lambda req, exc: JSONResponse({"error": str(exc)}, status_code=500))
C. @app.exception_handler(Exception) async def global_exception_handler(request, exc): return JSONResponse(status_code=500, content={"error": str(exc)})
D. app.add_exception_handler(Exception, lambda request, exc: JSONResponse({"error": "Error occurred"}, status_code=500))

Solution

  1. Step 1: Understand middleware vs exception handler

    Middleware wraps all requests and can catch exceptions globally; exception handlers are per-exception but not middleware.
  2. Step 2: Check for logging and JSON response in middleware

    @app.middleware('http') async def global_exception(request, call_next): try: return await call_next(request) except Exception as e: print(f"Error: {e}") return JSONResponse(status_code=500, content={"error": "Internal server error"}) uses @app.middleware('http') with try-except, logs error with print, and returns JSONResponse with status 500.
  3. Step 3: Verify other options

    app.add_middleware(ExceptionMiddleware, handler=lambda req, exc: JSONResponse({"error": str(exc)}, status_code=500)) uses add_middleware incorrectly; C and D are exception handlers, not middleware.
  4. Final Answer:

    @app.middleware('http') async def global_exception(request, call_next): try: return await call_next(request) except Exception as e: print(f"Error: {e}") return JSONResponse(status_code=500, content={"error": "Internal server error"}) -> Option A
  5. Quick Check:

    Middleware with try-except and logging = @app.middleware('http') async def global_exception(request, call_next): try: return await call_next(request) except Exception as e: print(f"Error: {e}") return JSONResponse(status_code=500, content={"error": "Internal server error"}) [OK]
Hint: Use @app.middleware('http') with try-except and logging [OK]
Common Mistakes:
  • Confusing middleware with exception handlers
  • Using add_middleware incorrectly for exceptions
  • Not logging exceptions inside middleware