SenchaCon 2016: Expect the Unexpected - Dealing with Errors in Web Apps

188 views

Published on

Dealing with unexpected exceptions on the server side is something we've all done for ages. Now it's time to apply the same quality goals and monitoring to our JS codebase. This is especially important for Sencha applications where the front-end usually contains 100k+ lines of code. I'll demonstrate various powerful monitoring techniques and tricks that we are using ourselves at Bryntum.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
188
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SenchaCon 2016: Expect the Unexpected - Dealing with Errors in Web Apps

  1. 1. Expect the unexpected - dealing with errors in web apps Mats Bryntse Founder, @bryntum
  2. 2. Who is Mats Bryntse? • From Stockholm, Sweden • Working with Ext JS since 2007 • mankz in the Sencha forums • Founder of Bryntum (Scheduler, Gantt, Kanban Taskboard, Siesta) • @bryntum
  3. 3. What is a javascript Error?
  4. 4. Javascript error basics • Javascript errors are unhandled exceptions happening in your code base • Or in the frameworks you use • Doesn’t matter where it happens, poor user impression regardless • With JS codebases in the size of MBs, we can no longer ignore error handling + logging • Good news - it’s easy ?
  5. 5. What does the user see when there is a JS error? ?
  6. 6. Nothing, unless you show them ?
  7. 7. The ErrorEvent constructor • When an error happens, an ErrorEvent is fired on the window object • ErrorEvent.message • ErrorEvent.filename • ErrorEvent.lineno • ErrorEvent.colno // Normal browsers only • ErrorEvent.error // Normal browsers only
  8. 8. Global error handler // Old school window.onerror = function(message, source, lineno, colno, error) { … }; window.addEventListener(‘error’, function(event) { // event.message // event.filename // event.lineno // event.colno // good browsers only // event.error (has stack property, in good browsers) }, true); …or by listening to the window ‘error’ eventListen with capture=true to also get notified of resource load errors Errors are easily caught in window.onerror
  9. 9. You can throw your own Error too // Bad, no call stack will be available throw ‘My own error’; // preferred throw new Error(‘This will have call stack’); try { // Questionable code goes here } catch(e) { // log error } finally { // always called } • throw a String • Or better, an Error instance (callstack) • Catch using simple try/catch/finally
  10. 10. The error reporting cycle
  11. 11. What’s the typical strategy for error reporting at Enterprise X?
  12. 12. Flow of an error - Enterprise version Error in web app Reports to own support Your company User realises it’s an error 01010 10110 11110 User Dear User, /Depressed dev. Can’t reproduce, need more info. Sincerely yours,
  13. 13. Too much guessing… 🕵🕵
  14. 14. 10 points “Add-to-cart button doesn’t work”
  15. 15. 9 points ‘a is undefined’
  16. 16. 9 points ‘console.lgo is not a function’
  17. 17. 8 points line 1, column 536171
  18. 18. 7 points
  19. 19. 6 points
  20. 20. 5 points Step by step: First login as user Add few items to cart Click checkout button => crash
  21. 21. Logging and monitoring errors in your web app
  22. 22. Logging is easy • Log message, file, line, stack etc.. • Add any extra meta relevant for your debugging (userId/name/…) • Poor mans error logger: function log(msg) { new Image().src = "log.php?msg=" + encodeURIComponent(msg); } window.onerror = log; throw new Error("Ooops");
  23. 23. Saving error info • Store error logs in some database on a non-production server • Throttle logging on client side + server side • Probably we only care about the first error on a page
  24. 24. Flow of an error - Improved version Error in web app Your company User realises it’s an error 01010 10110 11110 User
  25. 25. Making sense of a callstack is sometimes easy…
  26. 26. …but often it takes a lot of detective work 🕵🕵
  27. 27. Solving a complex puzzle Connecting the dots… undefined is not a function
  28. 28. Bryntum - How we (used to) handle errors
  29. 29. Online examples is a test suite of sorts
  30. 30. Previous error handling at Bryntum • Web site visitors are test monkeys unknowingly === free help • Errors logged in a DB • Emails sent to devs = Very useful for finding and rapidly fixing bugs
  31. 31. Error handling at Bryntum Instant feedback Site visitors / “Late QA”Developers
  32. 32. Error handling at Bryntum • What we had was pretty good, not great • Lots of time spent playing detective, looking at callstacks • Just error message, filename, callstack isn’t enough to rapidly locate root cause • We would like to know more… 🕵🕵
  33. 33. Wish list…
  34. 34. Function arguments Know how the crashing function was called function getUserInfo(id) { var user = this.store.getById(id); // => null return user.getInfo(); // Cannot call getInfo of null } getUserInfo(-1); // crashes, would be neat to know input args
  35. 35. Logs about failed ajax requests Usually produces errors that are less tested (aka happy testing)
  36. 36. See how the application looked at the time of crash ?
  37. 37. Know what the user did during page session 🕵
  38. 38. What if there was a tool that did all this…? 🕵🕵
  39. 39. Introducing the new shiny…
  40. 40. Detailed data about users environment
  41. 41. Capturing arguments passed to the crashing function
  42. 42. Screenshot at the time of the error
  43. 43. Support for hiding sensitive data before screenshot
  44. 44. + environment data collected Many things to consider… • OS • Browser • Window size • Touch support • Window blur/focus events • Date + Timezone • Language • Failed ajax requests • Cookie state • Network connectivity events
  45. 45. Timeline visualising activity Shows ajax requests, window resizing, hide/show, connectivity
  46. 46. Notifying the developers
  47. 47. Notifying the affected user • Optional popup for the user that triggered the error • Shows status of the error (New, Reproduced, Fixed)
  48. 48. Two way communication Error data posted Current error status [new/reproduced/fixed] Users / QADevelopers
  49. 49. Cuts 99% of communication out • No need for QA to email devs about crash reports • No need for devs to notify QA that bug is already fixed
  50. 50. DEMO TIME
  51. 51. Installing the logger in your app var logger = new Err.ErrorLogger({ recordUserActions : true, maxNbrLogs : 1, logResourceLoadFailures : true, applicationId : ‘your-cool-app‘, version : ‘2.0.0-rc.1’, logAjaxRequests : true, enableScreenshot : true, saveCookies : true, frameworkVersion : Ext.versions.extjs.version }); logger.addTag('ReadOnlyUser', true); logger.addTag('Secret Flag', 'XYZ');
  52. 52. In a dream world we would be able to: See on the user’s machine when error happens live Reproduce the error on in production Reproduce the error locally �
  53. 53. DEMO TIME
  54. 54. BETA release imminent Beta testers wanted! mats@bryntum.com Launch December 2016 Summing up:
  55. 55. Questions?

×