Overview
Stringboot is designed to fail gracefully, but it’s important to handle errors properly to provide the best user experience. This guide covers error handling patterns for all platforms.Common Error Scenarios
Network Errors
Network Errors
When it happens: No internet connection or server unreachableSDK behavior: Automatically falls back to cached dataUser impact: No visible error if data is cachedAction needed: Inform users that content may be outdated
Missing Strings
Missing Strings
When it happens: String key doesn’t exist in any languageSDK behavior: Returns
"??key??" formatUser impact: Visible placeholder textAction needed: Provide fallback text or log for debuggingAuthentication Errors (401/403)
Authentication Errors (401/403)
When it happens: Invalid or expired API tokenSDK behavior: Logs error, uses cached data, disables syncUser impact: App works with cached data but won’t updateAction needed: Validate API token configuration
Rate Limiting (429)
Rate Limiting (429)
When it happens: Too many requests to serverSDK behavior: Automatic retry with exponential backoff (max 3 attempts)User impact: Slight delay in updatesAction needed: None - handled automatically
Server Errors (500+)
Server Errors (500+)
When it happens: Server-side issuesSDK behavior: Retry with backoff, fall back to cacheUser impact: May use slightly outdated contentAction needed: Check server status, report if persistent
Platform-Specific Error Handling
- Web SDK
- Android SDK
- iOS SDK
HTTP Status Code Handling
The SDK automatically handles these HTTP status codes:| Status Code | Meaning | SDK Response | Retry? |
|---|---|---|---|
| 200 | Success | Parse and cache data | N/A |
| 304 | Not Modified | Use existing cache | No |
| 401 | Unauthorized | Log error, use cache | No |
| 403 | Forbidden | Log error, use cache | No |
| 404 | Not Found | Language doesn’t exist | No |
| 429 | Rate Limited | Exponential backoff | Yes (3x) |
| 500-599 | Server Error | Retry with backoff | Yes (3x) |
| Network Error | No connection | Use cache immediately | No |
Best Practices
Always Use try/catch
Wrap all SDK operations in try/catch blocks to handle unexpected errors
Provide Fallbacks
Always have fallback text for missing strings
Show Loading States
Indicate when operations are in progress
Log Errors
Log errors for debugging and monitoring
Don't Block UI
Never block the main thread waiting for network operations
Test Offline
Test your app in airplane mode to ensure offline functionality
Handle Edge Cases
Account for missing strings, slow networks, and API errors
Monitor in Production
Use error tracking to identify issues in production
Error Logging
Enable Debug Logging
Production Error Tracking
Integrate with your error tracking service:Testing Error Scenarios
Simulate Network Errors
- Web
- Android
- iOS