Enterprise JavaScript Error Handling (Ajax Experience 2008)
Upcoming SlideShare
Loading in...5
×
 

Enterprise JavaScript Error Handling (Ajax Experience 2008)

on

  • 41,895 views

My presentation at Ajax Experience 2008 about error handling strategies for JavaScript.

My presentation at Ajax Experience 2008 about error handling strategies for JavaScript.

Statistics

Views

Total Views
41,895
Views on SlideShare
31,555
Embed Views
10,340

Actions

Likes
90
Downloads
737
Comments
6

33 Embeds 10,340

http://www.devhands.com 5017
http://dzign.us 4865
http://tswiki 118
http://localhost:8888 77
https://twitter.com 50
http://www.linkedin.com 31
http://www.slideshare.net 30
url_unknown 25
http://scotland.groupdocs.com 23
http://webcache.googleusercontent.com 15
http://www.dzign.us 15
http://rustyroy.blogspot.com 9
https://www.linkedin.com 9
http://ulhoo.com 9
http://subjot.com 6
http://localhost:4298 6
http://librobackbone.com 5
http://www.redditmedia.com 4
http://feeds.feedburner.com 4
http://www.e-presentations.us 3
http://rustyroy.blogspot.co.uk 3
http://paper.li 2
http://translate.googleusercontent.com 2
http://localhost 2
http://boutofcontext.com 2
http://rustyroy.blogspot.ca 1
http://dev.groupdocs.dynabic.com 1
https://si0.twimg.com 1
http://dzign-us.tumblr.com 1
http://dzign.us:8888 1
https://twimg0-a.akamaihd.net 1
http://1522195990.nvmodules.netvibes.com 1
https://trovepromo-tf.trove-stg.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Enterprise JavaScript Error Handling (Ajax Experience 2008) Enterprise JavaScript Error Handling (Ajax Experience 2008) Presentation Transcript

  • E nterpris e JavaS cript E rror Handling Nicholas C . Zakas P rincipal Front E nd E ngineer, Yahoo!
  • Who's this g uy? • P rincipal Front E nd E ngineer, Yahoo! Front P age • YUI C ontributor • Author
  • Ques tion: What do us ers s ee when there's a JavaS cript error on a web pag e?
  • Ans wer: Nothing !*
  • “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
  • R ule #1: As s ume your code will fail
  • My code is beautiful and never fails
  • As s umption? • What if destination is null? • What if source is null?
  • R ule #2: Log errors to the s erver
  • S imple Log g ing
  • R ule #3: You, not the brows er, handle errors
  • try-catch • Thrown errors contain extra information • E rrors that are caught are considered to have been handled
  • window.onerror • Last stop before browser responds • R eturn true to indicate not to respond • O nly supported in Internet E xplorer and Firefox
  • E rror Lifecycle Browser Error window.onerror try-catch Error
  • R ule #4: Identify where errors mig ht occur
  • Types of E rrors • Type coercion errors
  • Type C oercion E rrors
  • Types of E rrors • Type coercion errors • D ata type errors
  • Data Type E rrors • O ften occurs with function arguments • Typically a symptom of insufficient value checking
  • Data Type E rrors
  • Data Type E rrors
  • Data Type E rrors - Fixed
  • Data Type E rrors - Fixed
  • Types of E rrors • Type coercion errors • D ata type errors • C ommunication errors
  • C ommunication E rrors • Invalid UR L/post data • S erver response status • No network connection • S erver response content
  • 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
  • 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
  • S erver R es pons e S tatus
  • 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)
  • No Network C onnection
  • 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
  • R ule #5: Throw your own errors
  • Throw Your Own E rrors
  • B rows er R es ponds
  • 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
  • R ule #6: Dis ting uis h fatal vers us non- fatal
  • 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
  • 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
  • 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
  • Fatal or Non-Fatal?
  • R ule #7: Provide a debug mode
  • 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
  • Debug Mode
  • Debug Mode
  • S ummary
  • 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
  • Ques tions ?
  • E tcetera • M y blog: www.nczonline.net • M y email: nzakas@ yahoo-inc.com
  • Happy debug g ing !
  • 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/