Describe a robust error handling strategy for network requests

WHAT THIS TESTS: The interviewer wants to see if you think in layers. Network code fails in three distinct places: the transport layer cannot reach the server, the server returns an unhappy HTTP status, or the payload does not match the expected schema. A senior candidate demonstrates that each layer needs its own detection path and user-facing strategy.

A GOOD ANSWER COVERS: First, catch DioException and inspect its type field. DioExceptionType.connectionTimeout, receiveTimeout, or connectionError indicate a network connectivity problem, so you should suggest retry logic with exponential backoff and a user message about checking their connection. Second, when type is DioExceptionType.badResponse, examine the Response statusCode. A 404 means the resource is missing, a 401 or 403 means authentication or authorization failed, and a 500 range means a server-side error; each should map to a different domain exception or UI state. Third, after you confirm the status code is successful, parse the response body. Wrap JSON deserialization in its own try-catch because a 200 OK can still contain malformed JSON or an unexpected schema; this isolates serialization bugs from transport bugs. Fourth, mention logging and telemetry. Connectivity errors might be retried silently, 5xx errors should be logged to your crash reporter as warnings, and JSON parse errors should be logged as critical data contract violations.

COMMON WRONG ANSWERS: Catching every exception generically and showing a single generic toast message. Treating HTTP 404 or 500 as a network connectivity error and retrying indefinitely. Parsing JSON directly inside the same catch block that handles DioException, which makes it impossible to tell whether the failure came from the wire or from the mapper. Ignoring the response body when the status code is non-2xx, which wastes useful server error messages.

LIKELY FOLLOW-UPS: How would you implement retry with exponential backoff without blocking the UI? What do you do when the server returns 200 but the JSON contains an error field instead of the expected payload? How do you cancel an in-flight request when the user leaves the screen? How would you write unit tests for each failure layer without making real network calls?

ONE CONCRETE EXAMPLE: Suppose you call dio.get to fetch a user profile. The phone is in airplane mode, so Dio throws DioExceptionType.connectionError; your handler emits a NetworkFailure state and shows an offline banner. Next, you turn off airplane mode but the user ID does not exist; Dio returns a 404 with DioExceptionType.badResponse; your handler emits a NotFoundFailure and shows a profile not found screen. Finally, you request a valid ID, the server returns 200, but the JSON omits the required email field; your JSON mapper throws a FormatException; your handler emits a DataCorruptionFailure and logs the exact payload to your monitoring dashboard so the backend team can fix the contract.

Source: dio 5.9.2 on pub.dev