Forum Discussion

Manfred_F's avatar
Manfred_F
Regular Contributor
10 years ago
Solved

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:


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


  • AlexKaras's avatar
    AlexKaras
    10 years ago
    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?

14 Replies

Sort By
  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    10 years ago
    Hi Manfred,



    I am afraid that you are mixing two error types and this is the reason of the problem that you have.

    First error type is system runtime errors. And this is handled with the On Error... vbs statement. The following pseudo-code is an example of this error type:

    z = 0

    On Error Resume Next

    k = 5 / z

    iRes = Err.Number

    If (0 <> iRes) Then

      Log.Error(...)

    End If



    Without been handled, the errors of this type usually prevent the script code from further execution.



    The errors of the second type are errors logged by TestComplete's engine. Those errors can be handled using TestComplete's event handlers like OnLogError, OnLogMessage, etc.

    You may treat those errors like 'logical' ones. They are based on the following fundamental TestComplete's concept:

    -- if some tested object is addressed via its full path (e.g. Sys.Process().Window().Panel().TextBox() ), then all objects mentioned in the path must exist. If some object does not exist, then the error is logged to the test log.



    So, if you are using 'absolute' path to address your tested object, this, according to TestComplete's architecture, means that you are sure that all objects in this path must exist. And if not, then TestComplete logs an error to the log to let you know that this or that object did not exist during test runtime. You may consider this functionality as a constant implicit verification of tested objects existence.

    If you are not sure whether or not some object along the path should exist, then instead of 'absolute' addressing you must use either some WaitXXX() function (WaitChild, WaitPanel(), etc.) or its Extended Find equivalent in NameMapping and then check if the sought for object was found.



    There were requests from the users with the QTP experience to change TestComplete's behavior so that it does not log an error if some object within the 'absolute' path does not exist and let user explicitly check if the object was found or not. Personally I prefer TestComplete's behavior, because it immediately lets you know that some object does not exist and frees you from routine checking if the sought for object was found and thus prevents from obscured runtime errors that may be a result of some object not been found many test code lines above.



    Enabled StopOnError TestComplete's setting stops test execution if any error is posted to the log, either of the first type (which will stop test code execution by itself because this is OS runtime problem) or of the second type.

    If you expect that some code line may trigger the error of the first type (runtime one), than you should surround this line with the On Error Resume Next / On Error GoTo 0 lines (note that this is extremely bad programming style to use On Error Resume Next as the first line of test code).

    If you are not sure that all parent objects in the hierarchy to the required tested object will exist, than you should either use the FindXXX() functions to get the required tested object, or analyze and handle the error in the OnLogError() handler.



    Hope the above will help...
  • gid_216's avatar
    gid_216
    Frequent Contributor
    10 years ago
    HI,



    Add Runner.Stop afetr Log.Error so the script will stop. You can use the same in LogEvent On Error.



    Code Snippet


    log.Error "Systemmenue-Element " & PVA_0.Basis.NameWrap(ItemNameOrIx) & _" nicht gefunden", mcModul & cRoutine



    Runner.Stop



    Hope this helps


  • Manfred_F's avatar
    Manfred_F
    Regular Contributor
    10 years ago
    Hi,

    this would stop my test after the log.Error statemen, right.

    But:

    I would have to add the code for each Log.Error Statement...

    And it would not influence unforeseen Errors ..



    Regards,

    Manfred

  • Manfred_F's avatar
    Manfred_F
    Regular Contributor
    10 years ago
    Hi Alexei,

    thank You very much for Your detailled answer.



    In general, I agree to distinguish runtime Errors from Logical Errors, of course. But sometimes there are circumstances, where things mix up..



    Take a look at the following code:




    Function



    CallSystemMenu( _



    DlgCtrl, _



    byVal



    ItemNameOrIx _



    )



    ' Systemmenüpunkt rufen



    Const cRoutine = "CallSystemMenu"



    Dim Item



    Dim FolderId



    Dim Ergebnis



    Dim DlgCaption



    Dim ItemCaption



    Dim Ilc



     



    ItemNameOrIx = ItemIxStr(ItemNameOrIx)



    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



     



    ' verschwindet beim Schließen



    DlgCaption = DlgCtrl.WndCaption



    ItemCaption = Item.Caption



     



    ' Log-Folder



    FolderId = Log.CreateFolder("Dialog " & DlgCaption & " Systemmenue, " _



    & Item.Caption, mcModul & cRoutine)



     



    Log.PushLogFolder FolderId



    Ergebnis = Item.Enabled



    If Ergebnis Then DlgCtrl.SystemMenu.Click ItemNameOrIx



    If Ergebnis Then



    ' Log



    log.Message "Dialog " & DlgCaption & " Systemmenue, '" _



    & ItemCaption & "' aktiviert", mcModul & cRoutine



    Else



    log.Message "Dialog " & DlgCaption & " Systemmenue, '" _



    & ItemCaption & "' war nicht enabled", mcModul & cRoutine



    End If



    ' Log-Folder



    log.PopLogFolder



    CallSystemMenu = Ergebnis



    End Function




    It calls a System menu entry for our legacy application.

    I want to log a detailled error message, if a non-existent item Name is handed in.

    For menus, there is no "exists" function, calling waitChild wouldn't help either, because it doesn't apply to Menus.

    I could iterate the Systemmenu's items and check the item.Caption, OK.

    But I prefer the above solution, guarding the Access to the item via error handling.

    When I do the error handling, I want to control the error process, of course. I don't want TC to generate Errors and/or stop execution in the protected code area. I want this to happen afterwards, if I decide to do so.





    There is a more weird Situation, where I Need vbs error handling:

    In the above function, the systemmenu behaves different, if the window is maximized. In this case, the menu is accessible and enabled, and so are all the items. But If I call


    DlgCtrl.SystemMenu.Click ItemId


    I get an error "unable to obtain System menu". The reason is, that in this case, the System menu in the main window has to be used.

    Now, the only way to have a transparent solution would be: try calling the dialog's System menu, on error try calling the main window's System menu. But this interferes with stop on Error = True, the test is aborted.



    I'm going to open a ticket for an Option to have both, StopOn Error and script error handling.



    Kind Regards,



    Manfred

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    10 years ago
    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?
  • Manfred_F's avatar
    Manfred_F
    Regular Contributor
    10 years ago
    Hi Alexei,



    thank You, once again, for Your Explanation.

    In fact, Your solution b) is Close to what I have implemented now.

    So far, OK.



    I've got one last remark:

    You said <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.>



    Well, Yes, there is a runtime error with err.Number 424 "Object required". This vb error would be handled perfectly by vbs, if TC would allow to do so (Stop on Error = FALSE), otherwise the run stops.



    I've posted a Feature request for this issue.



    Thank You again



    Kind Regards



    Manfred
  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    10 years ago
    Hi Manfred,



    >> Well, Yes, there is a runtime error with err.Number 424 "Object required". [...]

    To say the truth, I am really surprised. There must not be such error here. Are you sure that the error is triggered exactly by the mentioned line of code? Have you double-checked this using TC's debugger? (TestComplete will navigate to the code line that posted the error to the test log if you double-click the error line in the test log and the Call Stack tab in the test log contains the complete call stack (also with the clickable lines) that led to the error.)



    The reason for my questions is that, assuming that DlgCtrl is some tested object descendant from the Sys one (can you post here the full name of the DlgCtrl object?), it must not trigger runtime error.

    On the other hand, (and I am pretty sure that you already know this) the Err object is reset after execution of every script code line. Because of this (and this is illustrated in my code example), the value of the Err.Number *must* be saved to the variable and analyzed *immediately* after execution of the line of code that can trigger an exception. I don't see this in the code you provided. If value 424 is returned by the PVA_0.Basis.ObjectIsSet() function, this may mean that the actual problem occurs within this function, but is not triggered by the Set Item = ... line.



    My current understanding of what happens in your code is like this:

    a) On Error Resume Next line turns on VBS error handling

    b) Set Item = DlgCtrl.SystemMenu.Items(ItemNameOrIx) code line is executed but some object within the hierarchy is not found, thus the returned Item object contains only .Exists property which is set to False. At the same time, because you are using 'absolute' object identification and not using TC's OnLogError handler the error about not found object is posted to the test log by TC's engine;

    c) On Error GoTo 0 line turns off VBS error handling;

    d) The call to PVA_0.Basis.ObjectIsSet(Item) triggers exception in the ObjectIsSet() function (because it obtains invalid object) and this exception is posted to the test log and stops the overall test run (because of the disabled VBS error handling).



    Can you post here the error messages from TC's test log?
  • Manfred_F's avatar
    Manfred_F
    Regular Contributor
    10 years ago
    Hi Alexei,



    I'm happy to be able to give You some info back for Your effort ;-)



    Yes, I'm sure, that the code line in question Triggers the error. Navigating from the log gets me there, and I inserted an Output which Shows me the err objects state behind the line.

    If I step to the line, I get in the evaluate window for DlgCtrl.SystemMenu.Items(ItemId): undefined. vbs expects an object or Nothing and thus throws the error, I think.



    The DlgObject's full Name is <Sys.Process("pva").Window("SVMDIFRAME", "Open LS6000 PVA", 1).Window("MDIClient", "", 1).Window("SVMDICHILD", "<4> In Bearbeitung - Fasler\BDE_TEST_2.LDG", 1)>



    My code was:


    On Error Resume Next

    Set Item = DlgCtrl.SystemMenu.Items(ItemId)

    Log.Message Err.Number & " " & Err.Description

    On     Error GoTo 0


    (run with Stop On Error = false). The PVA_0.Basis.ObjectIsSet() function just delivers True for an object set and false for Nothing or non-objects.



    Your assumption about the SYS object is not true, because we not are working on a control but on a menu. The exists property doesn't apply.



    The log is (Stop on error False):

    Error: The control item 'asdf' not found. 16:12:13 Normal  [from line Set Item..]

    Message: 424 Objekt erforderlich 16:12:13 Normal    [from Log.Message Err.Number]

    Error: Dialog <4> In Bearbeitung - Fasler\BDE_TEST_2.LDG Systemmenue, 'asdf' nicht gefunden 16:12:14 Normal  [from Log.Error ...]



    Kind Regards,



    Manfred
  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    10 years ago
    Manfred,



    > DlgCtrl.SystemMenu.Items(ItemId): undefined.

    Just a wild guess - was DlgCtrl initialized with some value? Also, does SystemMenu object have Items[] property? And I hope that ItemId variable also contains correct value.



    > Your assumption about the SYS object is not true, because we not are working on a control but on a menu.

    Not sure I completely understood this...

    What I meant was that all objects that are accessible via TC's test engine are instantiated from the Sys root (or Device one in case of the mobile application). For those objects TC adds its support properties, wrappers, etc. TC also can work with regular COM objects (e.g. like Shell.Application one), but in this case it can use only methods/properties provided by the given COM object.



    My suggestion will be to set a breakpoint on the Set Item = ... line and investigate DlgCtrl and DlgCtrl.SystemMenu objects using the Evaluate window. Both of them must be valid objects with the .Exists property set to True (I assume that the full name you provided for the DlgObject was actually for DlgCtrl object).
  • Manfred_F's avatar
    Manfred_F
    Regular Contributor
    10 years ago
    Hi Alexei,



    > DlgCtrl.SystemMenu.Items(ItemId): undefined

    Well, DlgCtrl is valid, DlgCtrl.SystemMenu is valid, and ItemId contains a string (not an existing item Name, remember, I wanted to enhance the behavior in case of wrong values). In this case, the evaluate window Shows "undefined" and TC generates an error.

    Why does it? I just accessed the item, I didn't try to call one of its methods..



    > Your assumption about the SYS object is not true

    Of Course, DlgCtrl is a Control object derived from Sys root and behaves the Way it should. But: DlgCtrl.SystemMenu is a Menu object, having its own properties and behavior, not derived from Sys root. The Menu object does not have the Exists-property as far as I have seen in the help System.







    Regards,



    Manfred