Error handling in production in Flask - Performance & Optimization

Performance: Error handling in production

MEDIUM IMPACT

This affects page load speed and user experience by controlling how errors are managed and displayed without blocking rendering or causing layout shifts.

Handling server errors in a Flask web app in production

Flask

from flask import Flask, render_template
app = Flask(__name__)

@app.errorhandler(500)
def internal_error(error):
    return render_template('500.html'), 500

@app.route('/')
def index():
    1 / 0  # This will raise a ZeroDivisionError

if __name__ == '__main__':
    app.run(debug=False)

Disables debug mode and uses custom error pages to avoid blocking rendering and provide user-friendly messages.

📈 Performance GainNon-blocking error handling; improves INP by avoiding heavy error stack rendering.

Handling server errors in a Flask web app in production

Flask

from flask import Flask
app = Flask(__name__)

@app.route('/')
def index():
    1 / 0  # This will raise a ZeroDivisionError

if __name__ == '__main__':
    app.run(debug=True)

Debug mode is enabled in production causing detailed error pages to block rendering and expose sensitive info.

📉 Performance CostBlocks rendering with large error stack trace; increases LCP and INP negatively.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Debug mode with detailed error page	High (large DOM for stack trace)	Multiple reflows due to dynamic content	High paint cost for error details	[X] Bad
Custom minimal error page	Low (simple DOM)	Single reflow	Low paint cost	[OK] Good

Rendering Pipeline

When an error occurs, Flask either returns a detailed debug page or a custom error page. Debug pages block rendering with heavy content, while custom pages allow smooth style calculation and paint.

→HTML Parsing

→Style Calculation

→Layout

→Paint

⚠️ BottleneckLayout and Paint stages due to large error stack traces in debug mode

Core Web Vital Affected

INP

This affects page load speed and user experience by controlling how errors are managed and displayed without blocking rendering or causing layout shifts.

Optimization Tips

1Never run Flask with debug=True in production to avoid blocking rendering with heavy error pages.

2Use simple, custom error pages to minimize DOM size and paint cost during errors.

3Proper error handling improves user interaction responsiveness and avoids layout shifts.

Performance Quiz - 3 Questions

What is a performance downside of running Flask with debug=True in production?

A It reduces server response time.

B It blocks rendering with large error stack traces.

C It automatically caches error pages.

D It disables error handling.

DevTools: Performance

How to check: Record a session while triggering an error; observe if rendering is blocked or delayed by error page generation.

What to look for: Look for long tasks blocking main thread and large layout or paint times indicating heavy error page rendering.

Practice

1. What is the main purpose of using @app.errorhandler in a Flask application?

easy

A. To catch specific errors and provide custom responses

B. To speed up the application startup

C. To automatically restart the server on errors

D. To log user activities

Solution

1. Step 1: Understand the role of @app.errorhandler

   This decorator is used to catch specific HTTP or application errors in Flask.

2. Step 2: Recognize its use for custom responses

   It allows developers to return user-friendly error pages or messages instead of default error traces.

3. Final Answer:

   To catch specific errors and provide custom responses -> Option A

4. Quick Check:

   Error handling = custom responses [OK]

Hint: Errorhandler decorates functions to catch and respond to errors [OK]

Common Mistakes:

• Thinking it restarts the server automatically
• Confusing errorhandler with logging functions
• Assuming it speeds up app startup

2. Which of the following is the correct syntax to handle 404 errors in Flask?

easy

A. @app.error(404)
def not_found(error):
return 'Not found', 404

B. @app.errorhandler(404)
def not_found(error):
return 'Page not found', 404

C. @app.handle_error(404)
def not_found():
return 'Page missing', 404

D. @app.catch_error(404)
def not_found(error):
return '404 error', 404

Solution

1. Step 1: Identify the correct decorator name

   The correct Flask decorator for error handling is @app.errorhandler.

2. Step 2: Confirm function signature and return

   The function should accept an error parameter and return a response with the error code.

3. Final Answer:

   @app.errorhandler(404)\ndef not_found(error):\n return 'Page not found', 404 -> Option B

4. Quick Check:

   Correct decorator and function signature = @app.errorhandler(404) def not_found(error): return 'Page not found', 404 [OK]

Hint: Use @app.errorhandler with error code and error param [OK]

Common Mistakes:

• Using wrong decorator names like @app.handle_error
• Omitting the error parameter in the function
• Returning without the status code

3. Given this Flask code snippet, what will the user see if a 500 error occurs?

@app.errorhandler(500)
def internal_error(error):
    return 'Something went wrong, please try later.', 500

medium

A. The message: 'Something went wrong, please try later.' with status 500

B. A detailed Python traceback error page

C. A blank page with status code 500

D. The default Flask 404 error page

Solution

1. Step 1: Understand the errorhandler function

   The function returns a custom message and status code 500 when a 500 error occurs.

2. Step 2: Identify the user-visible output

   The user will see the returned string message with HTTP status 500, not the default traceback.

3. Final Answer:

   The message: 'Something went wrong, please try later.' with status 500 -> Option A

4. Quick Check:

   Custom error message shown = The message: 'Something went wrong, please try later.' with status 500 [OK]

Hint: Custom errorhandler returns your message, not default trace [OK]

Common Mistakes:

• Expecting Flask's default error page instead of custom message
• Thinking a blank page will appear
• Confusing 500 error with 404 error page

4. What is wrong with this Flask error handler code?

@app.errorhandler(403)
def forbidden():
    return 'Access denied', 403

medium

A. The return statement must include a JSON response

B. The decorator should be @app.handle_error

C. The function must accept an error parameter

D. The status code 403 is invalid

Solution

1. Step 1: Check function signature for errorhandler

   Flask error handler functions must accept the error argument to receive error details.

2. Step 2: Identify missing error parameter

   The function forbidden lacks the required error parameter.

3. Final Answer:

   The function must accept an error parameter -> Option C

4. Quick Check:

   Error handler function needs error param = The function must accept an error parameter [OK]

Hint: Error handler functions always take an error argument [OK]

Common Mistakes:

• Omitting the error parameter in handler functions
• Using wrong decorator names
• Assuming JSON response is mandatory

5. You want to show a friendly error page for all unhandled exceptions in production without exposing debug info. Which Flask setup is best?

hard

A. Use @app.route('/error') to manually show errors

B. Set app.debug = True to see detailed errors

C. Remove all error handlers to let Flask show default error pages

D. Use @app.errorhandler(Exception) to catch all errors and return a simple message

Solution

1. Step 1: Understand catching all exceptions

   Using @app.errorhandler(Exception) catches all unhandled errors globally.

2. Step 2: Provide user-friendly message without debug info

   Returning a simple message hides technical details, improving user experience and security.

3. Final Answer:

   Use @app.errorhandler(Exception) to catch all errors and return a simple message -> Option D

4. Quick Check:

   Global error handler with simple message = Use @app.errorhandler(Exception) to catch all errors and return a simple message [OK]

Hint: Catch Exception globally to hide debug info in production [OK]

Common Mistakes:

• Enabling debug mode in production
• Relying on default Flask error pages
• Using routes instead of error handlers for errors