Forum Discussion

ijaz5's avatar
ijaz5
Occasional Contributor
8 years ago

Error Event (GeneralEvents_OnLogError) wont trigger on VB script Runtime error

 I am trying to call some function or  do any event actions  when 'Microsoft VBScript runtime error' occur in log . 

 

GeneralEvents_OnLogError(Sender, LogParams) works fine when any sort of error occurs in script but how could I know that which error has caused run time error or when 'Microsoft VBScript runtime error' or 'Script execution was interrupted' is posted to the log. 

I want to call some other function when 'Microsoft VBScript runtime error' or 'Script execution was interrupted' is posted to the log.

 

Below is my code in which IF statment never go TRUE:

 

 

Sub GeneralEvents_OnLogError(Sender, LogParams)
Err.Clear
On Error Resume Next 
   If LogParams.MessageText = "Microsoft VBScript runtime error." or LogParams.MessageText = "Script execution was interrupted."then 
    Sys.Process("iexplore").Terminate()
    Delay(2000)
    Call Authenticated_login.Authenticated_login(1)
   end if

End Sub

 

Error I want to catch is also attached.

 

4 Replies

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3

    Hi,

     

    As basically already answered by others...

    The are two types of error messages in TestComplete.

    First type is of 'runtime engine' origin and are caused by the errors like division on zero, missing or incorrect function parameters, attempt to multiply string by two, etc. These errors are handled by the means of the given scripting language (try/catch, try/except, On Error Resume Next). I.e. these are programmatic errors. Errors of the first type are not handled by the OnLogError handler.

    Second error type is of 'TestComplete origin'. These errors are triggered when TestComplete cannot interact with the UI object directly referenced in test code. The reason for this may be because the referenced object was not found, or is overlapped by some other (modal) window (this also triggers OnOverlappedWindow or OnUnexpectedWindow event) or control, etc. I.e. these are 'logical', but not programmatic errors. Everything is correct from the scripting language point of view in this case. Errors of the second type can be handled using the OnLogError handler.

  • Manfred_F's avatar
    Manfred_F
    Regular Contributor

    In fact, we don't get a Standard error message from a runtime error.

     

    The appropriate way to react on unsafe functionality is to use script error handling. In VB:

     

    On Error Resume Next

    ' generate error

    Blah!

    log.Event "Error: " & err.Number, Err.Description

    If err.Number = 500 Then log.Event "got that beast"

    On Error GoTo 0

     

    Additionally, it may be necessary to do TC error handling (in case Your code throws a TC error).

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor

      Yep. Good call.  In JScript/JavaScript/CnScript it's try/catch.  DelphiScript uses try/except.  I think Python does as well.

      What you can do, then, is in the exception handling part of things, call Log.Error and pass it an error message... you can then trap that with the OnLogError event if you want... or, simply, handle the problem in the catch/except block.

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    I tried a similar deal with a JavaScript runtime error and got the same results.  And I think I know why.

    Microsoft VB Script Runtime errors and JavaScript runtime errors and similar errors don't play the same game as other types of errors that may occur during a test run.  While they show up in the log as an "Error" log type, they don't execute through the same code and, therefore, don't actually trigger an OnLogError event.

     

    So, while your code is 100% correct... because the event doesn't trigger, you'll never get what you want.  Those two error types kill the test run immediately, no matter what.

     

    If you want to actually do something when the test automation fails with either of those two errors, I'd suggest you look into implementing the OnStopTest event handler.  You don't have access, necessarily, to the contents of the log so you won't be able to detect WHY the test stopped, just that it stopped.  Give that a try.