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.
Related
I have a Javascript class that performs a number of validity checks using the data provided to the class. I am trying to figure out the best way to create a validate() function which would return one error or multiple errors. One way would be to return an array of errors. Another way would be to pass a delegate to the function which would fire whenever any error occurs. Another way would be to create an event that would be fired whenever any error occurs. Out of these 3, which would be the most appropriate for what I am trying to accomplish?
Returning an array makes the interface a bit complex. On the other hand, if I use a delegate or event, then the delegate function/event code could be a bit complex as well.
If I were going to be a user of your interface, then I'd like to be able to subscribe to certain subsets or levels of errors spat out from the object.
For example, lots of loggers out there act on the notion of a logging level (Verbose, Warning, or Error for example). You could provide an interface where your object is actually logging/pushing notifications for each type of error it encounters, but you expose different callbacks for each type of message. So your users will be able to decide what to listen to.
To answer your question though, I'd like to see all errors rather than just one. And I'd say keep them coming until I unsubscribe from the notifications.
We are using Backbone.js and having issues when running our WebDriver tests. We are getting the following error:
org.openqa.selenium.StaleElementReferenceException: Error Message => 'Element does not exist in cache'
Our understanding is that this is caused when we are finding an element, and executing an action on that element (e.g. click()). The element that we have found has gone 'stale', and we suspect that element has been re-rendered or modified.
We have seen lots of solutions that we are not keen on:
Use Thread.Sleep(...). We don't want explicit sleeps in our code
Using a retry strategy, either as a loop or try-catching the StaleElementReferenceException. We feel this is not the right/clean solution, and is prone to breaking in the future
Some people are using WebDriverWait and waiting until some javascript function execution returns true. We have seen people wait for notifyWhenNoOutstandingRequests(callback) in Angular, but can't find anything obvious for Backbone.
We are hoping there is a clean solution that does not involve explicit sleeping, or some form of looping. Any thoughts?
I looked into WebDriverWaits a bit more and I think i've come up with a combination of expectations that works for us:
wait.until(refreshed(elementToBeClickable(...)));
The refreshed expectation is a wrapper for other expectations that deals with StaleElementReferenceException, and the elementToBeClickable expectation checks the element is clickable. What is interesting is that looking at the source for the built in expectations, some of them deal with StaleElementReferenceExceptions, while others don't (e.g. presenceOfElementLocated) and need to be wrapped in the refreshed expectation, so I think that's what initially threw me off when I first looked at WebDriverWaits.
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.
I am working on a web application with most of the code written in javascript. This application is using backbone.js and It has all kinds of event listeners. Some view functions are listening to model change events, url change events or user interactions. It's really hard to tell how a specific function was called. Is there a way to get the entire trace of function calls that lead to current invocation?
Set a breakpoint at the start of the function in the debugger. When the breakpoint is hit, then examine the callstack in the debugger and you can see the function calls that led to this point.
Firebug for Firefox will show the stack, once it stops in breakpoint you set.
Do you need the stack for debugging purposes?
Or, do you intend to use this information inside your code to make some kind of decision?
If that were the case, you could check the value of the variable "this".
I am writing a Node.js application, and inside one of its code blocks various exceptions may be thrown (by 3rd party code I call). Now I want to react on these exceptions, hence I do:
try {
// Call 3rd party code
} catch (e) {
// Handle e
}
Basically, this works fine, but ... how do I differ between different exceptions?
They all unfortunately have Error as constructor, hence this is no viable way. I may use the message property, but of course this is not the nicest way (as I am dependent on the fact the the message will never change, which is - IMHO - more probable than that the constructor changes).
Any ideas?
PS: Concretely - I need to react on SSL error while trying to do a tls.connect. How do I detect that it's an SSL error?
Most errors that are system-level errors wrapped into javascript error objects will have a code property and errno you can compare against. The list is defined in uv.h in the node.js source code. That's probably your 2nd choice, with preference being
instanceof where possible
code or errno
message
But the fact is sometimes you just have to look at message. Given the dynamic and loose typing of javascript and the fact that exceptions in general don't play a big role in node.js, there will be cases where checking the message is the best you can do.
I would not recommend using a try/catch structure in Node, as I don't think it will work due to the asynchronous nature of Node (unless you're using basic, synchronous code).
Assuming you're utilizing asynchronous functions/packages, you'll probably have more luck checking the err status in a callback function.