113 lines
2.9 KiB
Markdown
113 lines
2.9 KiB
Markdown
# Error Handling in MyCrib Apps
|
|
|
|
Both iOS and Android apps now display detailed error messages from the API.
|
|
|
|
## How It Works
|
|
|
|
### Backend (Django)
|
|
The Django backend returns errors in a standardized JSON format:
|
|
|
|
```json
|
|
{
|
|
"error": "Error Type",
|
|
"detail": "Detailed error message",
|
|
"status_code": 400,
|
|
"errors": {
|
|
"field_name": ["Field-specific error messages"]
|
|
}
|
|
}
|
|
```
|
|
|
|
### Shared Network Layer (Kotlin Multiplatform)
|
|
|
|
#### ErrorResponse Model
|
|
Located at: `composeApp/src/commonMain/kotlin/com/example/mycrib/models/ErrorResponse.kt`
|
|
|
|
Defines the structure of error responses from the API.
|
|
|
|
#### ErrorParser
|
|
Located at: `composeApp/src/commonMain/kotlin/com/example/mycrib/network/ErrorParser.kt`
|
|
|
|
Parses error responses and extracts detailed messages:
|
|
- Primary error detail from the `detail` field
|
|
- Field-specific errors from the `errors` field (if present)
|
|
- Fallback to plain text or generic message if parsing fails
|
|
|
|
#### Updated API Calls
|
|
All TaskApi methods now use ErrorParser to extract detailed error messages:
|
|
- `getTasks()`
|
|
- `getTask()`
|
|
- `createTask()`
|
|
- `updateTask()`
|
|
- `deleteTask()`
|
|
- `getTasksByResidence()`
|
|
- `cancelTask()`
|
|
- `uncancelTask()`
|
|
- `markInProgress()`
|
|
- `archiveTask()`
|
|
- `unarchiveTask()`
|
|
|
|
### Android
|
|
|
|
Android automatically receives parsed error messages through the shared `ApiResult.Error` class. ViewModels and UI components display these messages to users.
|
|
|
|
**Example:**
|
|
```kotlin
|
|
when (result) {
|
|
is ApiResult.Error -> {
|
|
// result.message contains the detailed error from ErrorParser
|
|
showError(result.message)
|
|
}
|
|
}
|
|
```
|
|
|
|
### iOS
|
|
|
|
iOS receives parsed error messages through the `ApiResultError` wrapper class from the shared KMM module. ViewModels extract and display these messages.
|
|
|
|
**Example:**
|
|
```swift
|
|
if let errorResult = result as? ApiResultError {
|
|
self.errorMessage = errorResult.message // Contains detailed error from ErrorParser
|
|
}
|
|
```
|
|
|
|
## Error Message Format
|
|
|
|
### Simple Errors
|
|
```
|
|
Invalid task status
|
|
```
|
|
|
|
### Validation Errors with Field Details
|
|
```
|
|
Invalid data provided
|
|
|
|
Details:
|
|
• email: This field is required.
|
|
• password: Password must be at least 8 characters.
|
|
```
|
|
|
|
## Benefits
|
|
|
|
1. **User-Friendly**: Users see specific error messages instead of generic "Failed to..." messages
|
|
2. **Debugging**: Developers can quickly identify issues from error messages
|
|
3. **Consistent**: Both platforms display the same detailed errors
|
|
4. **Maintainable**: Single source of truth for error parsing in shared code
|
|
5. **Backend-Driven**: Error messages are controlled by the Django backend
|
|
|
|
## Testing
|
|
|
|
To test error handling:
|
|
|
|
1. Create a task with invalid data
|
|
2. Update a task with missing required fields
|
|
3. Try to perform actions without authentication
|
|
4. Observe the detailed error messages displayed in the UI
|
|
|
|
## Future Improvements
|
|
|
|
- Add error codes for programmatic handling
|
|
- Implement retry logic for specific error types
|
|
- Add localization support for error messages
|