This document discusses handling errors in web applications. It begins by explaining what JavaScript errors are and how they are typically invisible to users. It then discusses how to catch errors using window.onerror or addEventListener and logging errors to help debug issues. Ideal error handling involves logging detailed error information to a database and notifying developers. The document wishes for more context around errors, like function arguments or AJAX requests. It introduces a new error logging and monitoring tool that provides detailed user environment data, function arguments, screenshots, and a timeline to help developers debug issues more easily.

1. Expect the unexpected - dealing with
errors in web apps
Mats Bryntse
Founder, @bryntum

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. What is a javascript Error?

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. What does the user see when there is a JS
error?
?

6. Nothing, unless you show them
?

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. 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. 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. The error reporting cycle

11. What’s the typical strategy for error
reporting at Enterprise X?

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. Too much guessing…
🕵🕵

14. 10
points
“Add-to-cart button doesn’t
work”

15. 9 points ‘a is undefined’

16. 9 points ‘console.lgo is not a function’

17. 8 points line 1, column 536171

18. 7 points

19. 6 points

20. 5 points Step by step:
First login as user
Add few items to cart
Click checkout button => crash

21. Logging and monitoring errors in your web
app

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. 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. Flow of an error - Improved version
Error in web app
Your company
User realises it’s an error
01010
10110
11110
User

25. Making sense of a callstack is sometimes
easy…

26. …but often it takes a lot of detective work
🕵🕵

27. Solving a complex puzzle
Connecting the dots…
undefined is not a function

28. Bryntum - How we (used to) handle errors

29. Online examples is a test suite of sorts

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. Error handling at Bryntum
Instant feedback
Site visitors / “Late QA”Developers

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. Wish list…

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. Logs about failed ajax requests
Usually produces errors that are less tested (aka happy testing)

36. See how the application looked at the time of
crash
?

37. Know what the user did during page session
🕵

38. What if there was a tool that did all
this…?
🕵🕵

39. Introducing the new shiny…

41. Detailed data about users environment

42. Capturing arguments passed to the crashing function

43. Screenshot at the time of the error

44. Support for hiding sensitive data before
screenshot

45. + 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

46. Timeline visualising activity
Shows ajax requests, window resizing, hide/show,
connectivity

47. Notifying the developers

48. Notifying the affected user
• Optional popup for the user that triggered the error
• Shows status of the error (New, Reproduced, Fixed)

49. Two way communication
Error data posted
Current error status
[new/reproduced/fixed]
Users / QADevelopers

50. 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

51. DEMO TIME

52. 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');

53. 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
�

54. DEMO TIME

55. BETA release imminent
Beta testers wanted! mats@bryntum.com
Launch December 2016
Summing up:

56. Questions?