The only problem with that is I've made it seem that I know where the error will occur. Depending on the changes made in the program this error may occur at anyplace in the script or may never occur. I'm trying to find a way to handle this error when ever it occurs. SetTrap doesn't work because I have to handle three boxes (ErrorHandler, MessageBox, and Dr. Watson).
When the error occurs I get two choices.
1. Abort - which causes another error box to pup up followed by Dr. Watson and then closes the whole program.
2. Continue - which put me in a place where i can then continue with the script.
Since it may not be possible to continue from where the excption occured, I'll have the program abort and restart with the next script.
It sounds like you've got a thankless task - trying to get silktest scripts working on an app which is chronically unstable.
If your aut is erroring so often that you're trying to get silktest to code around it, do you think that automated testing in your way is the best use of your time at this stage of it's development?
Though I'm intrigued - what kind of testcase are you writing, that could be worth continuing with from exactly the point where the aut crashed?
This program is pretty stable. There is two parts to this environment; A database and the application itself. If there is any necessary changes or improvements in the database then the application has to be recompiled to match these changes. Only If there is mistakes in this process then this exception will occur or if there is a decision to make major changes then we would know and expect this Exception to happen until everything has been cleaned up. Instead of marking off all areas where we know these errors will occur we prefer to let silktest make note of the errors and continue. As stated above SetTrap doesn’t work for this situation because in most of the scripts it is already in use and SetTrap doesn’t seem to work with more than one action within the same script. Also we would like the caption and error message returned and SetTrap doesn’t seem to do this well.
Also as stated above there is two options when this does exception occur (Abort and Continue). Since there is the option of continuing we were just wondering if it was possible to do so but now thinking more about this it wouldn’t be wise or necessary. It would be better to have the program close and restart with the next script.
Continue also gave us no crashes or Dr. Watson that’s why it was looked at as an option. I also had problems with the if statements for handling the messageboxes after the Abort. They are working well now.
The main reason for scripting this way is that if the error does occur no matter how rare it is, it freezes the application and the computer cannot close the application or the errorhandler messagebox therefore leaving all the other scripts unexecuted. If we decide to run all the scripts and leave for a few hours to work on something else, returning to the computer with this error would be more time wasted then actually coding to handle this exception.
I think everything is working ok now. Thanks again for your comments and help.