Error Handling (Legacy)

These are high level guidelines about how any type of error should be handled depending on the context where the error occurs.

Detailed guidelines / discussion for particular causes of errors can be found in this document's sub-pages.

Error Submitting Data

A user is trying to post a comment, but the network request failed. Their comment did not get posted.

Use a standard dialog showing the error message and an "OK" button to dismiss the dialog
The dialog should persist until the user dismisses it (e.g. taps a button in the dialog or navigates back)
If the error is recoverable (for example, the user can retry the request), include an additional button to recover.

Use native design. (AlertDialog on Android; UIAlertController on iOS)

A user navigates to the Handouts screen for a course. The network request to load the handouts data fails, and we don't have a cached version.

Show the error within the content area of the screen.
The error should be persistent.
If the error is recoverable (for example, the user can retry the request), include a button to recover.

There's no "native" widget for this, we will use our own designs.

A user navigates to the Handouts screen for a course. The network request to load the handouts data fails, but we have an old cached version of the handouts for that course.
A user is looking at a list of discussions. They try to reload using a refresh button or pull-to-refresh gesture. The network request fails.

Show the cached data.
Show the error along the edge of the screen
The error should remain until dismissed by the user
The error should not block the user from interacting with other content on the screen.
If the error is recoverable (for example, the user can retry the request), include a button to recover.

On Android, prefer Snackbar. On iOS, we'll have a custom widget, similar to a Snackbar.