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.
Related
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.
I am trying to incorporate into my Automation scripts functionality that will prevent the whole script from stopping when an Object Does Not Exist Error for a web object occurs. Instead the script should catch the error and perform a different function and continue running other scripts.
I first tried a Try Catch block, but then I learned it cannot see the errors generated by TestComplete itself. I looked into the Event Handlers you can make via the tool as well, but they don't seem to make any sense for the solution I need.
Here is an example and what I am trying to do.
function TestPage() {
\\Some condition where it will only continue if no errors are raised
var testobj = Aliases.MappedName
testobj.Click
//more code
//goes here if an error occurs at any point
//executes a reset function.
I can suggest two possible approaches that can be used separately or together.
You can check an object for existence before trying to get it. When working with the Name Mapping tree, this can be done with help of the WaitAliasChild and WaitMappedChild methods. This method is the best if you know that an object can be missing at a specific test step.
You can handle the OnLogError event in order to handle errors you want. Using this handler, you can prevent the error from being posted to the test log. Also, you can disable the Stop on error project option to prevent TestComplete from stopping the test on error and stops execution from within the OnLogError event handler using the Runner.Stop method. This approach works if you do not know at which exactly test step the issue can occur.
Personally I prefer the first approach and treat the second situation as an issue in my test or the tested application.
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.
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.