is it possible to register an error or exception handler/function that will be executed when a javascript error or exception occurs? I just feel wrapping all codes in try/catch block seems very tedious and inefficient.
window.onerror = function (msg, file, line) {
// handle error here
}
Supported by:
Chrome 13+
Firefox 6.0+
Internet Explorer 5.5+
Opera 11.60+
Safari 5.1+
Andy E's answer (+1) tells you how to do it.
That said, JavaScript isn't really meant to have caught execeptions in the same sense that, say, Java does. If your code is throwing exceptions, pull up a console and use the debugger to fix them. JS exceptions are slow, and really not meant to be used for flow control. A method won't throw an exception unless there's a serious problem — and it's usually a programming error.
Here's an alternative answer than the window.onerror solution. This isn't something I've used in production, but is something that I just like because of the flexibility (i.e. you could use it to debug things like timing how long a method took or something).
Whilst you could probably pass window into it (don't quote me on that, and don't think it's a good idea) it does work if you have all your methods in an object:
(function(obj) {
for (var name in obj) {
if (typeof(obj[name]) == 'function') {
currentMethod = obj[name];
obj[name] = function() {
try {
currentMethod();
}
catch (e) {
alert('Exception Handler: ' + e);
}
};
}
}
}(myObject));
Here's it working: http://jsfiddle.net/jonathon/kpYnW/
Basically, it goes through each property in your object, finds the ones that are functions and wraps them in a try/catch (or whatever else you want).
Whether or not it's efficient is a different matter - I've just found it a very useful technique for debugging. Unfortunately I can't remember the original place I read it but if anyone knows, please add as a comment.
Related
I am interested in monitoring javascript errors and logging the errors with the callstack.
I am not interested to wrap everything in try-catch blocks.
According to this article http://blog.errorception.com/2011/12/call-stacks-in-ie.html
it's possible inside window.onerror "recursively call .caller for each function in the stack to know the previous function in the stack"
I tried to get the callstack:
window.onerror = function(errorMsg, url, lineNumber)
{
var stk = [], clr = arguments.callee.caller;
while(clr)
{
stk.push("" + clr);
clr = clr.caller;
}
// Logging stk
send_callstack_to_log(stk);
}
but only one step is possible even if the callstack was much longer:
(function()
{
function inside() {it.will.be.exception;};
function middle() {inside()};
function outside() {middle()}
outside();
})();
One step isn't interesting because onerror arguments give me even more information about it.
Yes, I tried it with IE according the article I mentioned above.
Remark: I also tried to open an account on "ERRORCAEPTION" to gather error log. I tested it with IE and "ERRORCAEPTION" recognize that the errors are coming from IE, but I can't find any callstack information in the log I've got there.
Unfortunately this log will not always be available, it lacks line numbers, you can not really rely on it.
Try https://qbaka.com
Qbaka automatically overload bunch of JavaScript functions like addEventListener, setTimeout, XMLHtppRequest, etc so that errors happening in callbacks are automatically wrapped with try-catch and you will get stacktraces without any code modification.
You can try atatus which provides javascript contextual error tracking: https://www.atatus.com/
Take a look here:
https://github.com/eriwen/javascript-stacktrace
That's the one I use on Muscula, a service like trackjs.
I have wrote a program to monitor js error. maybe it will help.
I used three kind of methods to catch exceptions, such as window.onerror, rewrite console.error and window.onunhandledrejection. So I can get Uncaught error, unhandled promise rejection and Custom error
Take a look here: https://github.com/a597873885/webfunny_monitor
or here: https:www.webfunny.cn
It will be help
This may be a bad question, but I've noticed that as I'm writing coding along using mootools When I've got some code that goes through callbacks, bindings and generally isn't just a straight forward function call, if there's an error it doesn't get picked up by either Firebug or Chrome's console it just silently fails, and I'm forced to track down the error using trys and such that don't give you handy information like the line of code that's failing. It's like writing code for IE6 all you have to go on is some opaque message like 'can not read 'x' of undefined.'
I realize that the question isn't specific enough to ask 'how do I avoid this' but does anyone else run into this problem and if so how do you work around it? I'm also a little confused how an error could be picked up by a try/catch block, but not the javascript console.
EDIT:
OK, I've come up with something that reproduces the error
say you've got a function
function foo(){
var x = value.blah;
}
if I call that function like foo() I rightly get an reference error in my console. If, however, I call it like
(function(){
foo.attempt();
})()
I get no error in the console, but if I change foo to be
function foo(){
try{
var x = value.blah;
} catch(e){console.log(e)}
}
the console will log e but of course without the handle 'line: whatever' information.
I have considerable experience fiddling with errors in JavaScript. I've mostly used Chrome for building my understanding but most of it applies to Firefox and Internet Explorer as well.
I can immediately debunk your assumption about silent JavaScript errors. They don't exist, Errors always show. There might be a bug in Firefox or the Chrome's webdev, but the errors are there.
The most common way for errors not to show up is because you're catching them yourself. Perhaps prematurely.
I've figured out what I think is the best strategy for catching errors:
1. Always throw things that are Errors or inherited from Errors.
Ex: not: throw "Precondition failed" but throw new Error("Precondition failed").
This is because Errors are weird in JavaScript (I have no other word for it). If you want a stacktrace (and heaven's yes you want a stacktrace) you'll need to throw an Error (and not a string).
2. Don't use window.onerror Not much to say here. It's useless. You have no control over what get's flung to this function. It might be your code, it might be a broken plugin that a visitor uses. Also, no stacktrace.
3. Have one (global) error handler / when to catch errors
JavaScript is event driven. This has some unexpected consequences. Observe the following code:
try {
setTimeout(function () {
throw new Error("nope! :D");
}, 1);
} catch (e) {
console.log(e);
}
You will not see this error. (Firebug / console will catch it though)
This is because the inner function runs in it's own event and the try-catch statement no longer applies to it. The correct way is:
try {
setTimeout(function () {
try {
throw new Error("nope! :D");
} catch (e) {
console.log("Hell yea!", e);
}
}, 1);
} catch (e) {
console.log(e);
}
Or just make a function that wraps a function in a try-catch:
function wrap(wrap_dat_func) {
return function () {
try {
wrap_dat_func.apply(wrap_dat_func, arguments);
} catch (e) {
// send to error handler
}
}
}
Use like:
setTimeout(wrap(function () {
// etc
}), 1);
So basically whenever you generate a new event, wrap the callback in your global try catch function. So wrap call to setTimeout, setInterval all DOM related events like onclick onload ondocumentready, also AJAX calls onreadystatechanged.
How to get proper stacktraces (over events!) is another long winded explanation.
OK. I may be splitting hairs here, but my code isn't consistent and I'd like to make it so. But before I do, I want to make sure I'm going the right way. In practice this doesn't matter, but this has been bothering me for a while so I figured I'd ask my peers...
Every time I use a try... catch statement, in the catch block I always log a message to my internal console. However my log messages are not consistent. They either look like:
catch(err) {
DFTools.console.log("someMethod caught an error: ",err.message);
...
or:
catch(ex) {
DFTools.console.log("someMethod caught an exception: ",ex.message);
...
Obviously the code functions properly either way but it's starting to bother me that I sometimes refer to "errors" and sometimes to "exceptions". Like I said, maybe I'm splitting hairs but which is the proper terminology? "Exception", or "Error"?
This is a bit subjective, but to me an error is when someone or something does something wrong, improper, or invalid. It could be a syntax error, a logical error, a read error, user error, or even a social error. It's an abstract concept.
An exception, on the other hand, is an object that is created and thrown when a certain condition occurs in code. It may or may not correspond to a conceptual error. So to me, the proper nomenclature is "exception".
The ECMAScript specification calls them exceptions. You might want to do likewise.
To make your logging more informative:
catch(ex) {
DFTools.console.log("someMethod caught an exception of type "
+ ex.name + ": ", ex.message);
You might also want to bear in mind that exceptions (unfortunately) can be of any type, and so don't necessarily have name and message properties:
catch(ex) {
if (ex.message && ex.name) {
DFTools.console.log("someMethod caught an exception of type "
+ ex.name + ": ", ex.message);
} else /* deal with it somehow */
As this is starting to look pretty cumbersome to repeat everywhere, you might want to capture it in a function:
function logExceptions(methodName, action) {
try {
action();
} catch (ex) {
if (ex.message && ex.name) {
DFTools.console.log("someMethod caught an exception of type "
+ ex.name + ": ", ex.message);
} else {
DFTools.console.log("someMethod caught a poorly-typed exception: " + ex);
}
}
}
Now you can say:
logExceptions(function() {
// do some risky stuff...
});
In JavaScript it is called Error Catching. So I would suggest you use error instead of exception.
Leave the choice in the middle by using "e". Like in the examples of Mozilla.
Mozilla Core JavaScript 1.5 Reference
Exception is something you may expected for example in an attempt to open a file may face a "File not found exception". On the other hand, errors are something you may not see it coming like stack over flow or not enough memory.
An exception is an alternative logical way out off a function that does not produce a logical result. An exception also allows a better explanation of what happen why it exist this way. For File opening, again, a file handle is a logical result and if the file is not exist (one possible exception) or it is a folder not a file (another possible exception).
MAJOR DISCLAIMER: I don't consider that there is a "right" answer to this. The views expressed here are subjective and personal. What's more is that the ideas I'm about to espouse are only useful if you are going to do different things with different, ahem, faults... as you might using a system as per Daniel Earwicker's informative answer. With that in mind:
I contend that "an EXCEPTION is exceptional". An ERROR is less unexpected.
disclaimer: The following pseudo-code is not good; it merely serves as the minimum case I could think of to illustrate my point.
note: in this thought experiment, GetFile returns UNDEFINED if it cannot find the specified file.
function AlwaysGetFile(name){
var file = null;
if(FileExists(name)){
file = GetFile(name);
if(typeof file === "undefined"){
throw new "couldn't retrieve file" EXCEPTION
}
}
else{
throw new "file does not exist" ERROR
}
return file;
}
In the case that a consumer calls GetFileOrThrow with a filename that doesn't exist, an ERROR will occur. To my mind the distinction is really that higher-level code (or user input) is doing something wrong... this function must pass an ERROR up the line to that higher-level code which can decide what to do about this result. Consider it like this... this function would be saying to any consuming functions:
Look, my friend, I know what's going on here: it is an ERROR to request BobAccounts.xml, so don't do it again! Oh, and if you think you now know what might have gone wrong (having abused me), go ahead and try to recover from it!
Now consider the case that this function takes the name, checks that the file exists and then for some reason fails to retrieve it. This is a different situation. Something really unexpected has happened. What's more, the consuming code isn't to blame. Now we really want this function to say to any consuming functions:
Oh fiddlesticks! Sorry about this, I humbly beg your pardon but something EXCEPTIONAL that I don't really understand has gone wrong. I don't think that your request for BobAccounts.xml was unreasonable... and I know I should be fulfilling it for you. Since I'm lower level code than you, I really ought to know what's going on... but I don't... and since you've less chance than me of understanding this EXCEPTIONAL situation, I think you'd probably best just stop what you're doing and let this message go all the way to the top... I mean, there is something seriously fishy going on here.
So I suppose my summary is this: If the mistake happened in higher order code (you were passed bad data) throw an ERROR. If the mistake happened in lower order code (a function you depended on failed in a way you didn't understand and couldn't plan for) throw an EXCEPTION... and if the mistake happened in the function you are currently writing... well, duh, if you're aware of it then fix it!
And, finally, to answer the original question more directly: In terms of handling ERRORS and EXCEPTIONS, my advice would be: Handle all ERRORS gracefully (optionally logging them)... but handle EXCEPTIONS carefully indeed; only try to recover from an EXCEPTION if you are really sure you know what it is and why it's happened, otherwise let it bubble up (rethrowing it if you have to).
What you get in a Catch block is an Exception, so I name it as an exception...
If it is an error - I can handle it in my code & I usually don't expect to see it in the Catch block
HTH.
function testFun() {
onerror = function() { log("caught the error"); return true; };
setTimeout(function() { throw "bad bad bad"; }, 300);
};
This is sample, code, but it demonstrates a problem.
If I run this in FF, or IE7, it prints the sensible "caught the error" message (assume a reasonable 'log' function).
However if I debug the code in VS2008, the debugger stops on the throw with the message: 'Microsoft JScript runtime error: Exception thrown and not caught'. If I say 'continue' or 'ignore', the log message is not produced.
This is a problem since the real code I am working with is much larger than this, and I'll occasionally want to, you know, debug stuff. So two questions:
Any know why and can I modify this behaviour with some flag I don't know about?
Am I doing what I think I'm doing (setting the global 'onerror' handler) in this code? If not, what is the appropriate pattern for catching this type of error?
Note: There is no difference wrt this problem if I use window.onerror instead.
According to this defining a global onerror function doesn't work in IE. They were probably talking about IE6 or earlier, so maybe MS have fixed it for IE7 - however I wouldn't expect this to just automatically flow through to the VS debugger.
At any rate, try using window.onerror = function rather than just onerror.
If that doesn't work, you'll have to use a try/catch block inside your timer function I guess.
PS: Get firefox and use firebug. the debugger (and everything else) is much better and nicer to use than the VS debugging
What is the best technique for catching ALL exceptions thrown within JavaScript?
Obviously, the best technique is to use try...catch. But with ansynchronous callbacks and so forth, that can get tricky.
I know IE and Gecko browsers support window.onerror, but what about Opera and Safari?
Here are a bunch of test-cases that I would like to have a central exception handling solution for:
// ErrorHandler-Test1
var test = null;
test.arg = 5;
// ErrorHandler-Test2
throw (new Error("Hello"));
// ErrorHandler-Test3
throw "Hello again";
// ErrorHandler-Test4
throw {
myMessage: "stuff",
customProperty: 5,
anArray: [1, 2, 3]
};
// ErrorHandler-Test5
try {
var test2 = null;
test2.arg = 5;
} catch(e) {
ErrorHandler.handleError(e);
}
// ErrorHandler-Test6
try {
throw (new Error("Goodbye"));
} catch(e) {
ErrorHandler.handleError(e);
}
// ErrorHandler-Test7
try {
throw "Goodbye again";
} catch(e) {
ErrorHandler.handleError(e);
}
// ErrorHandler-Test8
try {
throw {
myMessage: "stuff",
customProperty: 5,
anArray: [1, 2, 3]
};
} catch(e) {
ErrorHandler.handleError(e);
}
If you think of any other test-cases, please mention them. Several of these cases mention a ErrorHandler.handleError method. This is just a suggested guideline when using try...catch.
If you use a library like jQuery for assigning all your event handlers, you can use a combination of window.onerror and wrapping the jQuery event handler code and on ready function with an error handling function (see: JavaScript Error Tracking: Why window.onerror Is Not Enough).
window.onerror: catches all errors in IE (and most errors in Firefox), but does nothing in Safari and Opera.
jQuery event handlers: catches jQuery event errors in all browsers.
jQuery ready function: catches initialisation errors in all browsers.
WebKit (Safari, Chrome, etc) now appears to support onerror.
Original post: As far as I know, WebKit/Safari does not support the onerror event. Which is a damn shame.
Actually, the jquery approach isn't so bad. See:
http://docs.jquery.com/Events/error#fn
and:
$(window).error(function(msg, url, line){
$.post("js_error_log.php", { msg: msg, url: url, line: line });
});
Catch all exceptions with your own exception handler and use instanceof.
$("inuput").live({
click : function (event) {
try {
if (somethingGoesWrong) {
throw new MyException();
}
} catch (Exception) {
new MyExceptionHandler(Exception);
}
}
});
function MyExceptionHandler(Exception) {
if (Exception instanceof TypeError ||
Exception instanceof ReferenceError ||
Exception instanceof RangeError ||
Exception instanceof SyntaxError ||
Exception instanceof URIError ) {
throw Exception; // native error
} else {
// handle exception
}
}
MyExcetpionHandler will throw native error as there is no try-catch block.
Visit http://www.nczonline.net/blog/2009/03/10/the-art-of-throwing-javascript-errors-part-2/
try-catch is not always the best solution. For example, in Chrome 7.0 you lose the nice stack trace in the console window. Rethrowing the exception does not help. I don't know of any solution which preserves stack traces and letting you react on exception.
With a little bit of work it's possible to get stacktraces that are reasonably complete in all browsers.
Modern Chrome and Opera (i.e. anything based around the Blink rendering engine) fully support the HTML 5 draft spec for ErrorEvent and window.onerror. In both of these browsers you can either use window.onerror, or (amazingly!) bind to the 'error' event properly:
// Only Chrome & Opera pass the error object.
window.onerror = function (message, file, line, col, error) {
console.log(message, "from", error.stack);
// You can send data to your server
// sendData(data);
};
// Only Chrome & Opera have an error attribute on the event.
window.addEventListener("error", function (e) {
console.log(e.error.message, "from", e.error.stack);
// You can send data to your server
// sendData(data);
})
Unfortunately Firefox, Safari and IE are still around and we have to support them too. As the stacktrace is not available in window.onerror we have to do a little bit more work.
It turns out that the only thing we can do to get stacktraces from errors is to wrap all of our code in a try{ }catch(e){ } block and then look at e.stack. We can make the process somewhat easier with a function called wrap that takes a function and returns a new function with good error handling.
function wrap(func) {
// Ensure we only wrap the function once.
if (!func._wrapped) {
func._wrapped = function () {
try{
func.apply(this, arguments);
} catch(e) {
console.log(e.message, "from", e.stack);
// You can send data to your server
// sendData(data);
throw e;
}
}
}
return func._wrapped;
};
This works. Any function that you wrap manually will have good error handling.
You can send data using image tag as follows
function sendData(data) {
var img = newImage(),
src = http://yourserver.com/jserror + '&data=' + encodeURIComponent(JSON.stringify(data));
img.crossOrigin = 'anonymous';
img.onload = function success() {
console.log('success', data);
};
img.onerror = img.onabort = function failure() {
console.error('failure', data);
};
img.src = src;
}
However you have to do backend to collect the data and front-end to visualise the data.
At Atatus, we are working on solving this problem. More than error tracking, Atatus provides real user monitoring.
Give a try https://www.atatus.com/
Disclaimer: I am a web developer at Atatus.
It is true that with modern browsers, hooking window.onerror for errors that bubble all the way to the top along with adding jQuery event handlers for Ajax errors will catch practically all Error objects thrown in your client code. If you're manually setting up a handler for window.onerror, in modern browsers this is done with window.addEventListener('error', callback),
while in IE8/9 you need to call
window.attachEvent('onerror', callback).
Note that you should then consider the environment in which these errors are being handled, and the reason for doing so. It is one thing to catch as many errors as possible with their stacktraces, but the advent of modern F12 dev tools solves this use case when implementing and debugging locally. Breakpoints etc will give you more data than is available from the handlers, especially for errors thrown by third-party libraries which were loaded from CORS requests. You need to take additional steps to instruct the browser to provide this data.
The key issue is providing this data in production, as your users are guaranteed to run a far wider array of browsers and versions than you can possibly test, and your site/app will break in unexpected ways, no matter how much QA you throw at it.
To handle this, you need a production error tracker which picks up every error thrown in your user's browsers, as they use your code, and sends them to an endpoint where the data can be viewed by you and used to fix the bugs as they happen. At Raygun (disclaimer: I work at Raygun) we've put a bunch of effort into providing a great experience for this, as there's many pitfalls and issues to consider that a naive implementation will miss.
For instance, chances are you'll be bundling and minifying your JS assets, which means that errors thrown from minified code will have junk stacktraces with mangled variable names. For this, you need your build tool to generate source maps (we recommend UglifyJS2 for this part of the pipeline), and your error tracker to accept and process these, turning the mangled stacktraces back into human-readable ones. Raygun does all this out of the box, and includes an API endpoint to accept source maps as they are generated by your build process. This is key as they need to be kept non-public, otherwise anyone could unminify your code, negating its purpose.
The raygun4js client library also comes with window.onerror for both modern and legacy browsers, as well as jQuery hooks out-of-the-box, so to set this up you only need to add:
<script type="text/javascript" src="//cdn.raygun.io/raygun4js/raygun.min.js" </script>
<script>
Raygun.init('yourApiKey').attach();
</script>
There's also a bunch of functionality built-in including the ability to mutate the error payload before it is sent, adding tags and custom data, metadata on the user who saw the error. It also takes the pain out of getting good stack traces from the above-mentioned third-party CORS scripts, which solves the dreaded 'Script Error' (which contains no error message, and no stack trace).
A more crucial issue is that due to the huge audience on the web, your site will generate many thousands of duplicate instances of each error. An error tracking service like Raygun has smarts to roll these up into error groups so you don't drown in a flood of notifications, and lets you see each actual error ready to be fixed.
I was also looking for error handling and stacktrace and logging for user actions this is what i found hope this also helps you
https://github.com/jefferyto/glitchjs