@@ -25,7 +25,7 @@ categories:
25
25
maintenance) or unexpected (server crash!).
26
26
* ** Unexpected Errors:** These are errors that likely indicate a bug in
27
27
the application, such as unhandled exceptions.
28
-
28
+
29
29
Almost every application will have instances of each of these error categories
30
30
at some point. Handling each appropriately is key to keeping users who
31
31
encounter errors from becoming angry users.
@@ -64,7 +64,7 @@ to the end user.
64
64
65
65
There are many ways to implement error handling in a JavaScript application.
66
66
You may define a global error handler that can display messages passed to it,
67
- or have each component or control handle its own errors.
67
+ or have each component or control handle its own errors.
68
68
69
69
One clean way to handle errors is to define a common schema for all of your
70
70
application's errors and use the browser's built-in event system to "bubble
@@ -83,7 +83,20 @@ will be:
83
83
soon. Check back in a while, and if it's still not working contact support.
84
84
* ** Contact us.** Something is wrong in an unexpected place. Get in touch with
85
85
support as this isn't likely to get better on its own.
86
-
86
+ * ** Here's your data.** There will always be users who forget to copy their
87
+ text before they hit submit, and it shouldn't be their responsibility in the
88
+ first place. It's your UI's duty to cherish the effort that users put in
89
+ crafting some of their input, and thus at the very least, offer them means
90
+ to save their own backup of their work when your app fails to do so properly.
91
+ * This includes taking forever. If your modal "Saving…" dialog blocks
92
+ access to their composed message for more than a few seconds,
93
+ users are entitled to get angry.
94
+ * You can still use modal dialogs if they (at least after a short wait)
95
+ offer a button to give read-only access to the input data.
96
+ Make sure the button (and any timers for it) work in the most fail-safe
97
+ ways you can think of. Avoid any chance of replacing or obfuscating it
98
+ with another modal error message that triggers half a second later.
99
+
87
100
When handling client-side errors, you often have another choice to make:
88
101
halt the application or allow it to continue running. If the error only applies
89
102
to part of your system, you may want to allow the user to continue using the
@@ -120,7 +133,7 @@ wrong with the server). The most common statuses for web application errors are:
120
133
we don't know what error." It's the catch-all.
121
134
* ** 503 Unavailable:** The server is experiencing an outage, either planned or
122
135
unplanned.
123
-
136
+
124
137
Know these codes, and know them well, and you'll be well on your way to handling any
125
138
error that comes your way via an AJAX request.
126
139
0 commit comments