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.
08448380779 Call Girls In Civil Lines Women Seeking Men
Â
Expect the unexpected - dealing with errors in web apps
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
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 ?
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
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,
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
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âŠ
đ”đ”
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
?
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
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
ïżœ