35:"/_next/static/chunks/0_6qdgbl18thf.js" 36:"/_next/static/chunks/3316o_1ddm9ab.js" 37:I[96601,["$1","$22","$23","$35","$36"],"default"] 38:I[58709,["$1","$22","$23","$35","$36"],"default"] 39:I[80423,["$1","$22","$23","$35","$36"],"default"] 3a:T4ec,import requests import time def fetch_with_retry(url, max_retries=3): """Fetch URL with exponential backoff retry.""" for attempt in range(max_retries): try: print(f"Attempt {attempt + 1}/{max_retries}: {url}") response = requests.get(url, timeout=10) response.raise_for_status() print(f"✓ Success on attempt {attempt + 1}") return response.json() except requests.RequestException as e: # Calculate exponential backoff: 1, 2, 4 seconds wait_time = 2 ** attempt # If not last attempt, wait and retry if attempt < max_retries - 1: print(f"❌ Failed: {e}") print(f" Retrying in {wait_time}s...") time.sleep(wait_time) else: # Final failure print(f"❌ All {max_retries} attempts failed") print(f" Error: {e}") return None # Test with endpoint that randomly fails print("Testing retry logic:") data = fetch_with_retry('https://httpbin.org/status/500') if data: print("Unexpected success!") else: print("Correctly gave up after retries") 3b:Tc7c,import requests import time from typing import Optional, Dict, Any class ResilientAPIClient: """Production-ready API client with error handling.""" def __init__(self, base_url: str, timeout: int = 10, max_retries: int = 3): self.base_url = base_url self.timeout = timeout self.max_retries = max_retries self.cache = {} # Simple cache for fallback def _should_retry(self, status_code: Optional[int]) -> bool: """Determine if error is worth retrying.""" if status_code is None: # Network error return True # Retry 5xx server errors, not 4xx client errors return 500 <= status_code < 600 def get(self, endpoint: str, **kwargs) -> Optional[Dict[str, Any]]: """Make GET request with resilient error handling.""" url = f"{self.base_url}/{endpoint}" cache_key = url for attempt in range(self.max_retries): try: response = requests.get(url, timeout=self.timeout, **kwargs) # Success if response.status_code == 200: data = response.json() self.cache[cache_key] = data # Cache for fallback return data # Check if we should retry if self._should_retry(response.status_code): wait_time = 2 ** attempt if attempt < self.max_retries - 1: print(f"⚠️ HTTP {response.status_code}, retrying in {wait_time}s...") time.sleep(wait_time) continue else: # Client error, don't retry print(f"❌ Client error {response.status_code}: {url}") return self.cache.get(cache_key) # Return cached if available except requests.Timeout: print(f"⚠️ Timeout on attempt {attempt + 1}") if attempt < self.max_retries - 1: time.sleep(2 ** attempt) continue except requests.RequestException as e: print(f"⚠️ Request error: {e}") if attempt < self.max_retries - 1: time.sleep(2 ** attempt) continue # All attempts failed - return cached data if available print(f"❌ All attempts failed for {url}") cached = self.cache.get(cache_key) if cached: print("✓ Returning cached data") return cached # Test client = ResilientAPIClient('https://httpbin.org') # Test successful request print("\n1. Testing successful request:") data = client.get('get') if data: print(f"✓ Success: {data.get('url')}") # Test timeout print("\n2. Testing timeout (should retry):") data = client.get('delay/10') # Will timeout and retry # Test 4xx error (shouldn't retry) print("\n3. Testing 404 (should not retry):") data = client.get('status/404') # Test 5xx error (should retry) print("\n4. Testing 500 (should retry):") data = client.get('status/500') 3c:T622,import requests import time def should_retry(status_code): """Determine if HTTP error is worth retrying.""" # Retry server errors (5xx) and network issues if status_code is None: # Network error return True if 500 <= status_code < 600: # Server error return True if status_code == 429: # Rate limit - retry with backoff return True # Don't retry client errors (4xx) return False def smart_fetch(url, max_retries=3): """Fetch with intelligent retry logic.""" for attempt in range(max_retries): try: response = requests.get(url, timeout=10) # Success if response.status_code == 200: return response.json() # Check if we should retry if should_retry(response.status_code): if attempt < max_retries - 1: wait = 2 ** attempt print(f"{response.status_code} error, retry in {wait}s") time.sleep(wait) continue else: # Client error - don't retry print(f"Client error {response.status_code} - not retrying") return None except requests.RequestException: if attempt < max_retries - 1: time.sleep(2 ** attempt) continue return None # Examples: # 404: Won't retry (client error) # 500: Will retry (server error) # 429: Will retry (rate limit) # Network error: Will retry3d:T45d,import requests class APIClientWithFallback: def __init__(self): self.cache = {} def get_data(self, key): """Fetch data with fallback to cache.""" url = f'https://api.example.com/data/{key}' try: response = requests.get(url, timeout=5) if response.status_code == 200: data = response.json() # Store in cache for future fallback self.cache[key] = data return data except requests.RequestException as e: print(f"⚠️ API failed: {e}") # Fallback to cached data if key in self.cache: print("✓ Returning cached data") return self.cache[key] # Final fallback to default print("⚠️ No cache available, using defaults") return {'status': 'unavailable', 'data': None} # Usage client = APIClientWithFallback() data = client.get_data('users') # If API fails: # 1. Try cached data # 2. Fall back to default # Better to show stale data than error page29:["$","div",null,{"className":"min-h-screen bg-gray-50 dark:bg-gray-900 pt-20","children":[["$","$L37",null,{"topicSlug":"python","topicTitle":"Python Engineer's Expedition","dayNumber":34,"dayTitle":"Error Handling in APIs","sprintNumber":2,"estimatedTime":"80 minutes","totalDays":66}],["$","div",null,{"className":"w-full px-4 sm:px-6 lg:px-8 py-8","children":["$","$L38",null,{"dayNumber":34,"topicSlug":"python","children":["$","$L39",null,{"day":{"dayNumber":34,"sprintNumber":2,"title":"Error Handling in APIs","subtitle":"When networks fail - building resilient applications","description":"Master timeout handling, implement retry logic with exponential backoff, and build resilient API clients that gracefully handle failures.","slug":"api-error-handling","week":5,"learningGoals":[{"id":"lg-day34-1","text":"Handle network timeouts and connection errors gracefully","measurable":"Set appropriate timeouts and catch timeout exceptions properly"},{"id":"lg-day34-2","text":"Implement retry logic with exponential backoff","measurable":"Create retry mechanism that waits 1s, 2s, 4s between attempts"},{"id":"lg-day34-3","text":"Build graceful degradation patterns for API failures","measurable":"Return cached or default data when API unavailable"},{"id":"lg-day34-4","text":"Log errors effectively for debugging production issues","measurable":"Create informative logs with context for troubleshooting"}],"whyThisMatters":{"productionStory":"A food delivery startup lost ₹50 lakhs in a single night when their payment gateway API had a 30-second outage. Without retry logic or timeouts, customer orders hung indefinitely. Users refreshed, creating duplicate orders. Restaurants prepared multiple orders. Chaos. After implementing proper error handling—5-second timeouts, 3 retries with backoff, fallback to alternative payment methods—they handled similar outages with zero customer impact. The lesson: APIs fail. Your error handling determines if you lose money or just log a warning.","realWorldContext":"In production, network requests fail 1-5% of the time. Mobile networks drop packets. DNS hiccups. Cloud servers restart. Rate limits kick in. Without proper handling: apps crash, users see errors, data corrupts, money is lost. Error handling isn't defensive coding—it's the difference between professional and amateur software.","industryRelevance":"SRE teams measure reliability in 'nines': 99% (down 3.6 days/year), 99.9% (down 8.7 hours/year), 99.99% (down 52 minutes/year). Each nine requires exponentially better error handling. Companies pay premium salaries for engineers who build resilient systems. This skill is mandatory for any production API work."},"topics":["Timeouts","Retries","Exponential Backoff","Graceful Degradation","Error Logging","Circuit Breakers"],"commonPitfalls":[{"id":"day34-pitfall-1","title":"Not setting timeouts on requests","howToFix":["Always set timeout parameter: requests.get(url, timeout=10)","Connection timeout vs read timeout: timeout=(3, 10)","Short timeout for user-facing, longer for background","Without timeout, requests hang indefinitely"],"whyItHappens":"Default is no timeout. A hung connection blocks your app forever. Always explicit timeouts."},{"id":"day34-pitfall-2","title":"Retrying immediately without backoff","howToFix":["Use exponential backoff: 1s, 2s, 4s, 8s between retries","Add jitter (randomness) to prevent thundering herd","Limit total retries to avoid infinite loops","Don't retry on 4xx errors (client errors)"],"whyItHappens":"Immediate retries hammer failing service. Backoff gives it time to recover."},{"id":"day34-pitfall-3","title":"Not distinguishing transient vs permanent failures","howToFix":["Retry 5xx (server errors) and network errors","Don't retry 4xx (client errors like 400, 404, 401)","429 (rate limit) needs special handling","Check error type before deciding to retry"],"whyItHappens":"Retrying a 404 wastes time—resource doesn't exist. Only retry transient errors."},{"id":"day34-pitfall-4","title":"Poor error messages and logging","howToFix":["Log URL, status code, full error message","Include context: user ID, request ID, timestamp","Use structured logging for searchability","Don't expose sensitive data in logs"],"whyItHappens":"Generic errors like 'Request failed' are useless for debugging. Context matters."}],"connections":{"previous":{"content":"Yesterday you learned API authentication. Now make your authenticated requests resilient to failures.","prerequisites":"Days 31-33 (API fundamentals and auth)"},"current":{"keyTakeaways":["Always set timeouts—without them requests can hang forever","Retry with exponential backoff for transient failures","Distinguish client errors (4xx, don't retry) from server errors (5xx, retry)","Log failures with context for debugging"]},"next":{"preview":"Tomorrow: Building a Data Fetcher with caching and batching","teaser":"Combine everything into a production-ready API client"}},"reflectionQuestions":[{"id":"day34-reflect-1","question":"Why is exponential backoff better than retrying immediately?","purpose":"Understand how backoff gives failing services time to recover"},{"id":"day34-reflect-2","question":"Which HTTP errors should you retry and which should you not?","purpose":"Learn to distinguish transient from permanent failures"},{"id":"day34-reflect-3","question":"What happens if you don't set a timeout on HTTP requests?","purpose":"Recognize the importance of timeout configuration"}],"resources":{"videos":[{"title":"Mastering Exception Handling with Python Requests","url":"https://www.youtube.com/watch?v=tNooKUkJhqo","duration":"15:42","description":"Exception handling with Python requests - timeouts, retries, exponential backoff","platform":"YouTube","language":"English"}]},"metadata":{"estimatedTime":"80 minutes","topics":["Timeouts","Retries","Error Handling"],"difficulty":"intermediate","prerequisites":["day-31","day-32","day-33"]},"challenges":[{"id":"challenge-1","difficulty":"basecamp","title":"Timeout Master","description":"Implement proper timeout handling for API requests","instructions":["Make request with 5-second timeout","Catch Timeout exception specifically","Return None or default value on timeout","Log timeout with URL for debugging"],"starterCode":"import requests\nfrom requests.exceptions import Timeout, RequestException\n\ndef fetch_with_timeout(url, timeout_seconds=5):\n \"\"\"Fetch URL with proper timeout handling.\"\"\"\n try:\n print(f\"Fetching: {url}...\")\n response = requests.get(url, timeout=timeout_seconds)\n response.raise_for_status()\n return response.json()\n \n except Timeout:\n print(f\"❌ Request timed out after {timeout_seconds}s\")\n print(f\" URL: {url}\")\n return None\n \n except RequestException as e:\n print(f\"❌ Request failed: {e}\")\n return None\n\n# Test with slow endpoint (delays 10 seconds)\ndata = fetch_with_timeout('https://httpbin.org/delay/10', timeout_seconds=3)\n\nif data:\n print(\"✓ Success!\")\nelse:\n print(\"✓ Handled timeout gracefully\")\n\n# Test with fast endpoint\ndata = fetch_with_timeout('https://httpbin.org/get', timeout_seconds=5)\nif data:\n print(f\"✓ Got response: {data.get('url')}\")\n","hints":["timeout parameter in seconds","Timeout exception is specific, catch it first","RequestException catches all requests errors","httpbin.org/delay/N delays N seconds"]},{"id":"challenge-2","difficulty":"ridge","title":"Retry with Exponential Backoff","description":"Implement retry logic that backs off exponentially","instructions":["Retry up to 3 times on failure","Wait 1s after 1st failure, 2s after 2nd, 4s after 3rd","Use 2**attempt for exponential backoff","Log each retry attempt with wait time"],"starterCode":"$3a","hints":["2**0 = 1, 2**1 = 2, 2**2 = 4 (exponential)","time.sleep() pauses execution","Don't sleep after final attempt","httpbin.org/status/500 always fails"]},{"id":"challenge-3","difficulty":"summit","title":"Resilient API Client","description":"Build production-ready client with timeouts, retries, and fallbacks","instructions":["Implement timeout handling","Add retry with exponential backoff","Only retry on 5xx errors and network failures","Return cached/default data on final failure","Log all failures with context"],"starterCode":"$3b","hints":["Cache successful responses for fallback","Only retry 5xx and network errors","4xx are client errors—don't retry","Return cached data when all else fails"]}],"coreContent":{"sections":[{"id":"section-1","type":"introduction","title":"Why Network Requests Fail","order":1,"content":{"explanation":"In production, API requests fail constantly. Network packets drop. DNS hiccups. Servers restart. Rate limits trigger. Mobile connections flicker. Your code must expect failure and handle it gracefully. The difference between hobby projects and production code is error handling—beginners assume success, professionals plan for failure."}},{"id":"section-2","type":"concept","title":"Setting Timeouts","order":2,"content":{"explanation":"Without timeouts, a hung request blocks your app forever. Always set timeout parameter.","codeExamples":[{"title":"Proper Timeout Configuration","code":"import requests\nfrom requests.exceptions import Timeout\n\n# ❌ BAD: No timeout (can hang forever)\n# response = requests.get('https://api.example.com/data')\n\n# ✅ GOOD: With timeout\ntry:\n # timeout in seconds\n response = requests.get(\n 'https://api.github.com/users/github',\n timeout=5 # 5 second timeout\n )\n print(f\"✓ Success: {response.status_code}\")\n \nexcept Timeout:\n print(\"❌ Request timed out after 5 seconds\")\n \n# Advanced: Separate connect and read timeouts\ntry:\n response = requests.get(\n url,\n timeout=(3, 10) # (connect_timeout, read_timeout)\n )\nexcept Timeout:\n print(\"Timeout occurred\")\n\n# Output if slow:\n# ❌ Request timed out after 5 seconds","language":"python","explanation":"Always set timeout. Single number = total timeout. Tuple = (connect_timeout, read_timeout)."}]}},{"id":"section-3","type":"concept","title":"Retry with Exponential Backoff","order":3,"content":{"explanation":"Retrying immediately floods failing services. Exponential backoff waits longer between each retry.","codeExamples":[{"title":"Exponential Backoff Pattern","code":"import requests\nimport time\n\ndef fetch_with_retry(url, max_retries=3):\n \"\"\"Fetch URL with exponential backoff.\"\"\"\n \n for attempt in range(max_retries):\n try:\n response = requests.get(url, timeout=10)\n response.raise_for_status()\n return response.json()\n \n except requests.RequestException as e:\n # Exponential backoff: 1s, 2s, 4s\n wait_time = 2 ** attempt\n \n if attempt < max_retries - 1:\n print(f\"Attempt {attempt + 1} failed\")\n print(f\"Waiting {wait_time}s before retry...\")\n time.sleep(wait_time)\n else:\n print(f\"All {max_retries} attempts failed: {e}\")\n return None\n\n# Usage\ndata = fetch_with_retry('https://api.example.com/data')\n\n# Retry schedule:\n# Attempt 1: Immediate\n# Attempt 2: After 1 second (2^0)\n# Attempt 3: After 2 seconds (2^1)\n# Attempt 4: After 4 seconds (2^2)","language":"python","explanation":"2**attempt gives exponential backoff. Waits 1, 2, 4, 8 seconds. Gives service time to recover."}]}},{"id":"section-4","type":"concept","title":"Smart Retry Logic","order":4,"content":{"explanation":"Don't retry everything. 4xx errors are client mistakes. Only retry transient failures.","codeExamples":[{"title":"Selective Retry Logic","code":"$3c","language":"python","explanation":"Retry 5xx, 429, and network errors. Don't retry 4xx—they're client mistakes that won't fix themselves."}]}},{"id":"section-5","type":"concept","title":"Graceful Degradation","order":5,"content":{"explanation":"When APIs fail completely, fall back to cached data or defaults. Better degraded service than complete failure.","codeExamples":[{"title":"Fallback Pattern","code":"$3d","language":"python","explanation":"Cache successful responses. On failure: return cache if available, else sensible defaults."}]}},{"id":"section-6","type":"visual-learning","title":"Video Learning Paths","order":6,"content":{"explanation":"Master error handling with production examples.","keyPoints":["See real-world error handling patterns","Learn when to retry and when to fail fast"]},"videoResources":[{"title":"Python Requests Tutorial: Request Web Pages, Download Images, POST Data, Read JSON, and More","creator":"Corey Schafer","embedId":"tb8gHvYlCFs","duration":"28:48","description":"Comprehensive requests tutorial covering timeout configuration and exception handling. Watch the error handling sections to understand how to manage connection errors and timeouts in production.","when":"Watch error handling sections to see timeout and exception handling"}]}]}},"topicSlug":"python","navigation":{"previous":{"dayNumber":33,"title":"API Authentication","sprintNumber":2},"next":{"dayNumber":35,"title":"Building a Data Fetcher","sprintNumber":2}},"dayNumber":34,"totalDays":66,"mathEnabled":false,"starterCode":"import requests\nfrom requests.exceptions import Timeout\n\n# ❌ BAD: No timeout (can hang forever)\n# response = requests.get('https://api.example.com/data')\n\n# ✅ GOOD: With timeout\ntry:\n # timeout in seconds\n response = requests.get(\n 'https://api.github.com/users/github',\n timeout=5 # 5 second timeout\n )\n print(f\"✓ Success: {response.status_code}\")\n \nexcept Timeout:\n print(\"❌ Request timed out after 5 seconds\")\n \n# Advanced: Separate connect and read timeouts\ntry:\n response = requests.get(\n url,\n timeout=(3, 10) # (connect_timeout, read_timeout)\n )\nexcept Timeout:\n print(\"Timeout occurred\")\n\n# Output if slow:\n# ❌ Request timed out after 5 seconds"}]}]}]]}]