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.
Related
So i have situation where I have to save the solution from a giant formula (calculation) to a variable and i know for sure that this will often have no solution so
I will use a try catch clause. And I can not calculate it twice because it would be, among possible other things, much too long (timewise).
But from what I know, with every catch, an exception object (etc) will get created. Is it possible to keep this from happening (some command or similar)?
Because I know for sure I will never need these because I know why it is impossible sometimes, but this automatic behavior would obviously cause unnecessary stack and processor (and that way runTIME) -usage.
Or is this default behavior not the case for js?
But from what I know, with every catch, an exception object (etc) will get created...
That's incorrect. An Error object will only be created if an error is thrown, not just because you have a catch block in your code. (And technically, in JavaScript, you can throw other things, they don't have to be Error instances, though when the browser or JavaScript engine throws something, it's always an Error object [directly or indirectly via a subclass].) If an error is created and thrown, and your code doesn't keep it, it'll immediately be eligible for garbage collection anyway. Creating and garbage collecting a single object is not a significant effort.
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.
I would like to assert, with an exception that cannot be caught.
something like an internal type.
the purpose is to stop execution at that point in the code (fail quickly when debugging), instead of getting caught in the calling side.
In dot net, MS implemented for that purpose an internal exception for code contracts, that cannot be caught.
Any other solution could work for me too.
I am new to javascript and typescript. if there is an idiomatic way to do that please let me know.
To "stop execution at that point in the code", You can use the keyword debugger.
This will pause the execution of the code, and you can then debug using your browser's inspector.
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.
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.