Skip to content

Error Handling: Allow users to backup their data. #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Error Handling: Allow users to backup their data. #21

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 17 additions & 4 deletions articles/front-end-error-handling/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ categories:
maintenance) or unexpected (server crash!).
* **Unexpected Errors:** These are errors that likely indicate a bug in
the application, such as unhandled exceptions.

Almost every application will have instances of each of these error categories
at some point. Handling each appropriately is key to keeping users who
encounter errors from becoming angry users.
Expand Down Expand Up @@ -64,7 +64,7 @@ to the end user.

There are many ways to implement error handling in a JavaScript application.
You may define a global error handler that can display messages passed to it,
or have each component or control handle its own errors.
or have each component or control handle its own errors.

One clean way to handle errors is to define a common schema for all of your
application's errors and use the browser's built-in event system to "bubble
Expand All @@ -83,7 +83,20 @@ will be:
soon. Check back in a while, and if it's still not working contact support.
* **Contact us.** Something is wrong in an unexpected place. Get in touch with
support as this isn't likely to get better on its own.

* **Here's your data.** There will always be users who forget to copy their
text before they hit submit, and it shouldn't be their responsibility in the
first place. It's your UI's duty to cherish the effort that users put in
crafting some of their input, and thus at the very least, offer them means
to save their own backup of their work when your app fails to do so properly.
* This includes taking forever. If your modal "Saving�" dialog blocks
access to their composed message for more than a few seconds,
users are entitled to get angry.
* You can still use modal dialogs if they (at least after a short wait)
offer a button to give read-only access to the input data.
Make sure the button (and any timers for it) work in the most fail-safe
ways you can think of. Avoid any chance of replacing or obfuscating it
with another modal error message that triggers half a second later.

When handling client-side errors, you often have another choice to make:
halt the application or allow it to continue running. If the error only applies
to part of your system, you may want to allow the user to continue using the
Expand Down Expand Up @@ -120,7 +133,7 @@ wrong with the server). The most common statuses for web application errors are:
we don't know what error." It's the catch-all.
* **503 Unavailable:** The server is experiencing an outage, either planned or
unplanned.

Know these codes, and know them well, and you'll be well on your way to handling any
error that comes your way via an AJAX request.

Expand Down