The document discusses best practices for handling JavaScript errors. It recommends 7 rules: 1) assume code will fail, 2) log errors to servers, 3) handle errors in code not browsers, 4) identify where errors may occur, 5) throw your own errors, 6) distinguish fatal from non-fatal errors, and 7) provide a debug mode. The document covers different types of errors and strategies for logging, catching, and displaying errors to users.

1. E nterpris e JavaS cript E rror
Handling
Nicholas C . Zakas
P rincipal Front E nd E ngineer, Yahoo!

2. Who's this g uy?
• P rincipal Front E nd E ngineer, Yahoo!
Front P age
• YUI C ontributor
• Author

3. Ques tion:
What do us ers s ee when
there's a JavaS cript error on
a web pag e?

4. Ans wer:
Nothing !*

5. “If an error is possible, someone will make it. The
designer must assume that all possible errors
will occur and design so as to minimize the
chance of the error in the first place, or its
effects once it gets made. E rrors should be
easy to detect, they should have minimal
consequences, and, if possible, their effects
should be reversible.”
-D onald A. Norman
The D esign of E veryday Things

6. R ule #1:
As s ume your code will fail

7. My code is beautiful
and never fails

8. As s umption?
• What if destination is null?
• What if source is null?

9. R ule #2:
Log errors to the s erver

10. S imple Log g ing

11. R ule #3:
You, not the brows er, handle
errors

12. try-catch
• Thrown errors contain extra information
• E rrors that are caught are considered to
have been handled

13. window.onerror
• Last stop before browser responds
• R eturn true to indicate not to respond
• O nly supported in Internet E xplorer and
Firefox

14. E rror Lifecycle
Browser Error
window.onerror
try-catch
Error

15. R ule #4:
Identify where errors mig ht
occur

16. Types of E rrors
• Type coercion errors

17. Type C oercion E rrors

18. Types of E rrors
• Type coercion errors
• D ata type errors

19. Data Type E rrors
• O ften occurs with function arguments
• Typically a symptom of insufficient value
checking

20. Data Type E rrors

21. Data Type E rrors

22. Data Type E rrors - Fixed

23. Data Type E rrors - Fixed

24. Types of E rrors
• Type coercion errors
• D ata type errors
• C ommunication errors

25. C ommunication E rrors
• Invalid UR L/post data
• S erver response status
• No network connection
• S erver response content

26. Invalid UR L/Pos t Data
• Typically long string concatenations
• D on't forget to use
encodeUR IC omponent() on each part
– Not encodeUR I()
• M ake sure parameters are named
correctly

27. S erver R es pons e S tatus
• 200 is not the only valid status that may
be returned
– Beware of 304
• Any other status means you didn't get
data

28. S erver R es pons e S tatus

29. No Network C onnection
• Internet E xplorer throws an error when
calling open() but then goes through
normal lifecycle
• Firefox fails silently but throws an error if
you try to access any response property
(status, statusText, responseText)

30. No Network C onnection

31. S erver R es pons e C ontent
• A status of 200/ 304 is not enough
• S erver errors often return HTM L
• If possible, set status to 500

32. R ule #5:
Throw your own errors

33. Throw Your Own E rrors

34. B rows er R es ponds

35. Throw or Try-C atch?
• E rrors should be thrown in the low-level
parts of the application
– Utilities, core libraries, etc.
• Use try-catch blocks in higher level parts
– Application-specific
– C lient-side business logic

36. R ule #6:
Dis ting uis h fatal vers us non-
fatal

37. Non-Fatal E rrors
• Won't interfere with user's main tasks
• Affects only a portion of the page
– E asily disabled/ignored
• R ecovery is possible
• A repeat of the action may result in the
appropriate result
• D on't tell the user it isn't working unless
absolutely necessary

39. Fatal E rrors
• The application absolutely cannot
continue
• S ignificantly interferes with user's ability
to be productive
• O ther errors will occur if the application
continues
• M essage the user immediately!
• R eload

41. Fatal or Non-Fatal?
• D on't allow your code to determine what
is and is not fatal
– Watch out for loops
• The user's experience comes first

42. Fatal or Non-Fatal?

43. R ule #7:
Provide a debug mode

44. Debug Mode
• Assign a variable that is globally
available
• try-catch should re-throw the error
• window.onerror should return false
• Allow the browser to handle the error

45. Debug Mode

46. Debug Mode

47. S ummary

48. R ules
1.Assume your code will fail
2.Log errors to the server
3.You, not the browser, handle errors
4.Identify where errors might occur
5.Throw your own errors
6.D istinguish fatal versus non-fatal
7.P rovide a debug mode

49. Ques tions ?

50. E tcetera
• M y blog: www.nczonline.net
• M y email: nzakas@ yahoo-inc.com

51. Happy debug g ing !

52. C reative C ommons Imag es
Us edcrazytales562/25148
• http:/www.flickr.com/
/ photos/
43252/
• http:/flickr.com/
/ photos/waldoj/126354436/
• http:/flickr.com/
/ photos/markhillary/289294549/
• http:/flickr.com/
/ photos/3fold/437853495/
• http:/flickr.com/
/ photos/ianhampton/ 65178598/
• http:/flickr.com/
/ photos/joshlewis/1596018210/
• http:/flickr.com/
/ photos/oberazzi/318947873/
• http:/flickr.com/
/ photos/ 27061495/
mc/