I am debugging the site with Chrome Developer Tools. If I check "pause on all exceptions", it pauses a few times when the site is loading and points to jquery.min.js(#line). These are only caught exceptions.
How can I track it back to see which function of my code causes the exception in jquery?
Also, should I really spend some time to track it down, if all my scripts function properly?
Thanks
Update. The problem is that I cannot see any of my functions in the call stack - only jquery calls:
Perhaps I can safely ignore these since all the exceptions are handled.
For issues like the one you're dealing with I find the printStackTrace method handy and keep it in my dev toolkit.
http://www.eriwen.com/javascript/js-stack-trace/
In a method where I'm having issues, I'll simply do the following:
var trace = printStackTrace();
console.log(trace);
I hope this might help you out. Good luck.
You can view the call stack in the debugger to see if your code caused the invoked code to throw an exception. Unfortunately, you may see some exceptions that were triggered within code running within a timer. Also, keep in mind that jQuery sometimes does a try..catch to detect browser traits, so you really should only be concerned with unhandled exceptions.
Related
I work on a Vaadin 8-based application. In a couple of hard-to-characterize scenarios - and I haven't been able to isolate the triggering factor - document.createElement starts to return undefined on all calls. This has been seen in both IE11 and Chrome (but in different circumstances in each case). My first theory was that it might be a browser out-of-memory issue, but I created a scenario with many more DOM elements that did not reproduce the error, and memory profiling showed no notable spike in memory usage at the point the problem happens. Also, when it happens it's at a predictable point in time - not random enough to be that sort of environmental issue.
When the problem happens, the console reports an odd status for the document.createElement function - it looks 'broken', but doesn't appear that it's just been clobbered by another function or something. Following is what the console shows under normal circumstances:
...while this is what shows after the problem occurs (plus a reference to a nonexistent attribute on document, to illustrate the difference between that and what createElement shows):
In Chrome the behavior in the console is similar:
Has anybody seen such a symptom in any browser and/or have any insight in tracking down the cause?
EDIT 17 January 2018: When I originally wrote this I only witnessed the problem behavior in IE11. Since then I have seen the same behavior under a different circumstance in Chrome.
My issue was that document.createElement was being replaced by some (buggy) injected anti-phishing JS I wasn't aware of. The problem with that JS is outside the scope of this question, but debugging tips provided in comments on the question were valuable in tracking it down:
The fact that document.createElement was being shadowed was discovered by noting that document.hasOwnProperty('createElement') returned true.
Defining a setter function for document.createElement that triggers the debugger helped me track down the offending code. I used the break-on-access snippet for this purpose, but also see simple code in this comment above for a roll-your-own alternative.
I'm new to Angular2 and have been charged with developing "robust error handling". So far I've followed the simplistic examples (console.logging) for adding custom error handling. But sometimes, if the page completely stops loading due to the error, we will want to redirect the user.
However sometimes, as below, although there are errors, the page otherwise loads completely. Are there are only certain types of errors that stop the page from completely loading? One of the following 6 types perhaps?
Any error can stop your page from rendering, depending on where it occurs in your process. Any error can fail to be caught if it is in a callback or other asynchronous action.
Be careful with terms like "robust error handling" - I've seen huge commercial projects that claim just that, but actually just silently truck over loads of issues, kind of like on error resume next.
I find the golden rules are:
If your app can continue through an exception (such as getting corrupt JSON data from a non-essential service) then that specific case should always be explicitly handled.
Otherwise a unexpected exception should always break something visible.
That second rule is counter intuitive, but it really is best practice. Users will complain about errors that they see, and visible exceptions and crashes will upset them and reduce their confidence in your application.
However, exceptions that they don't see still happened, and because you've silently trucked through them whatever caused them is still there. Silent exceptions cause data to be lost or corrupted. They cause the kind of bugs that you only find out about after 6 months in production. They cause the kind of bugs you can get sued over.
Users will forgive you for obvious errors that you fix quick, they will leave and never come back if you lose data and don't immediately know about it.
Ok, so that all said, the errors you seem to be highlighting are asynchronous, and related to a problem sometimes described as callback hell.
In your screenshot the error is from an HTTP GET request - this will typically be a method where you make an AJAX request, have a callback to fire when it succeeds, but don't have a callback to handle the exception.
Angular2 uses promises, which is the next error line of your screenshot. Promises wrap those callbacks and allow you to chain them - they really help with callback hell, but they're not a magic bullet: you have to make sure that every .then() has an error handler or a following .catch().
However, there is an even better way: with Angular2 you can use TypeScript, and that means you can use async and await. These are syntactic sugar for promises, but they also work with try-catch to make error handling of asynchronous exceptions much easier.
I've blogged about that in a lot more detail than I can fit here.
TL;DR: in Angular2 use async/await (with TS transpilation if you need it) to make sure that your Promise and callback exceptions make it back up, and then handle what you expect/can work around and visibly crash for what you can't.
How can one efficiently debug a component that extensively uses the scheduleDeferred/scheduleFinally calls?
For some reason some calls get swallowed and don't get executed. One option in mind is try to simplify the scenario until reaching a minimal number of interactions. But even then, it's not easy to see why the calls get swallowed by the browser.
If an exception occurs inside a callback/deferred method, it might just get swallowed and will not execute the next deferred call.
Sometimes you will see a JavaScript exception, but I already saw code where no exception was shown at all and just execution of this deferred call was stopped - pretty hard to find the cause.
I am just assuming you are using Super Dev Mode or running in production mode (compiled release) here, because in normal dev mode GWT should catch exceptions.
To protect against this, surround the content of every deferred call with a try/catch and either log or show a message if an exception occurs. That even will show an error if your breakpoint gets not triggered correctly.
We've been seeing an significant increase in the number of script errors reported in our app that uses the Realtime API. Specifically this started happening around 1/27/16 at ~6/7PM PST. Poking around a bit I believe I was able to track this back to the XHR error callback installed by the Realtime API.
function EA(a) {
a.onerror = function() {
self.xc()
}
}
In this handler self will always refer to window.self which seems like very much the wrong thing as there is never an xc function on the window object. While this doesn't appear to be causing any significantly bad behavior (although it may be contributing to further issues with re-connection), it would be great to have these errors handled.
Is this something other people are seeing as well or a known issue? Is anyone using a workaround?
This has been resolved and you should notice your errors diminish tomorrow when it is released.
This error does not cause any issues with re-connection. The onerror handler is invoked when there are network issues, which are (generally) automatically retried regardless of whether this particular execution path chokes at this point.
Is there a way to tell a browser, Opera or Chrome for example, not to stop scripts execution if it encounters an unhandled exception? I just need to test some JS scripts in browser but the page also includes some code for another (non-regular browser) execution environment hence modifying code as wrapping with try/catch isn't practical.
For Chrome I've tried to put code that sets a handler function to window.onerror which just returns true, then error didn't appear in console but execution of scripts aborted anyway.
To be specific the page contains code for Appcelerator Titanium platform, but I'm only testing general jQuery code so I'd like to do it in a browser.
If you call the suspect code in deferred fashion
setTimeout(THIS_MIGHT_THROW, 0)
then any errors thrown will terminate the "thread" or "micro-task", but not affect the rest of your execution.
As practical as your idea may seem, in reality it is impossible to enforce.
Comparatively, the Java programming language forces you to handle checked exceptions (exceptions you can recover from), while unchecked exceptions (such as RuntimeException - exceptions you cannot recover from) can just happen normally at runtime outside of your control. Since they are essentially unrecoverable, your program has to stop.
Exceptions raised from the JS JVM are, unlike in java, impossible to separate in checked and unchecked categories. Because there's no such a distinction, it is not possible to avoid the script to stop.
What if you divided function/infinity? How should you recover from that?
To each distinct scenario exists a distinct answer. This is why the only remaining and valid response to your concern is to use try catch block each time you're afraid an Exception will happen and stop your code, and handle it specifically to that situation.
As for the window.onerror event handler, it is irrelevant for this matter because it does not catch runtime exceptions, it catches the error that is raised when the original exception is not caught in a try catch block. That's why you get a magnificient "Uncaught exception: xxxxx" appended to the actual, original, exception message. The exception already happened, your script is already stopped, all you can do is display it the way you want at this point.