prevent stopping on handled vbs errors
Hi,
in my vbs script I want to use error handling.
If a non-existing Item is specified for System menu Access, I log an error for that item Name and then stop execution.
The problem is, that StopOnError does not interact with handled Errors, so the script stops in the protected code area as soon as the error occurs. It never gets a Chance to be handled by vbs.
When I turn off StopOnError, vbs error handling works, but the script will not stop on my generated Log.Error Event.
What would solve the Problem is a new Option as it exists in vb, "Stop on unhandled errors".
Any other ideas or comments would be appreciated.
Kind Regards,
Manfred
Code snippet:
in my vbs script I want to use error handling.
If a non-existing Item is specified for System menu Access, I log an error for that item Name and then stop execution.
The problem is, that StopOnError does not interact with handled Errors, so the script stops in the protected code area as soon as the error occurs. It never gets a Chance to be handled by vbs.
When I turn off StopOnError, vbs error handling works, but the script will not stop on my generated Log.Error Event.
What would solve the Problem is a new Option as it exists in vb, "Stop on unhandled errors".
Any other ideas or comments would be appreciated.
Kind Regards,
Manfred
Code snippet:
Set Item = Nothing
On Error Resume Next
Set Item = DlgCtrl.SystemMenu.Items(ItemNameOrIx)
On Error GoTo 0
If Not PVA_0.Basis.ObjectIsSet(Item) Then _
log.Error "Systemmenue-Element " & PVA_0.Basis.NameWrap(ItemNameOrIx) & _
" nicht gefunden", mcModul & cRoutine
- Hi Manfred,
Well... I seem to understand what you are not happy with, but also I think that I was not clear enough with my explanation, so I will try to extend it.
On Error clause is provided by the VBScript engine and is a handler for the runtime exception. For example, it will work for my sample when the code tries to divide by zero.
In the case of the
Set Item = DlgCtrl.SystemMenu.Items(ItemNameOrIx)
code line, this is perfectly valid line of code that does not trigger any exception. And thus the On Error handler will not be called by the VBScript runtime engine just because no exception was triggered.
So, there is no runtime error in this case.
However, it is possible that some object in the DlgCtrl.SystemMenu.Items(ItemNameOrIx) hierarchy will not exist during the test execution. As your test code uses 'absolute' path to the tested object (Items(ItemNameOrIx)), this means, according to the mentioned TestComplete's consept, that you expect that all objects along the hierarchy must exist. As this is not the case, TestComplete triggers 'logical' error and posts an error to the test log. These logical errors are provided by TestComplete, can be handled via OnLogError handler and VBScript runtime engine has absolutely no idea about them.
In your given case, I can suggest you two possible approaches (that are more generally applicable as well):
a) You leave your code as it is (optionally removing the On Error-related code) and implement the OnLogError handler. In this handler you should analyze the error and decide if the error message should be posted to the test log or not. See TestComplete's help for more details on how to implement this.
I should warn you that this is not a trivial approach and personally I prefer the second one;
b) You should change your test code so that it verifies if the required object exists and continue to use it or post an error to the test log / select alternative way.
This approach seems to me to be more close to the way how end-user works with the application. I.e. I don't think that end-user blindly tries to click the DlgCtrl.SystemMenu.Items(ItemNameOrIx) menu item and call your Support if this cannot be done. I hope that he/she checks first if the main window is maximized or not and then tries to access the proper menu. Then, upon clicking the required menu, he/she looks for the required ItemNameOrIx menu item. If the item is found, he/she clicks it. Otherwise he/she calls your Support (i.e. posts an error to the test log).
Likewise should your test code work. This approach let you do also a negative testing. What if from some version the menu does not depend on whether or not the application is maximized? In this case you should check the version of the tested application and do not work with different menu objects but, maybe, log an error if more than one menu object is available.
You should think about Stop On Error option as about the option that considers only 'logical' errors. This is because runtime errors stop code execution if they are not handled. Again, considering my example, VBScript runtime engine will stop code execution when the code tries to divide by zero if this attempt is not handled by its own means, i.e. by the means of the On Error clause. And if this attempt is handled, the exception will not be propagated to TestComplete's runtime engine and thus no error will be posted to the test log. But if the attempt to divide by zero is not handled via the On Error handler, then this exception will be propagated to TestComplete's engine which also does not handle it (just because this is pure runtime problem and thus must be handled there), the exception will be returned back to VBScript runtime for another (second) attempt to handle and not to be handled for the second time (because of the absence of the On Error clause), code execution will be stopped by the VBScript (or even OS) engine irrespective to the value of the Stop On Error option in TestComplete.
Does the above sounds reasonable? Does it help?
