Please use this information with extreme caution.
Our tests are not set to stop on error. We want the test to go to completion no matter what, so I do not know what effect this method will have when TestComplete is set to stop on the error event. It may stop, but not write the error to the log....
We had one message that we determined to be completely bogus. What we did was add some code to the GeneralEvents_OnLogError subroutine to not enter this error into the log. Substitute the error message that you want to suppress in the code below. It might be possible for you to make it Log.Warning when you encounter this message instead of an error by adding that line below....
Sub GeneralEvents_OnLogError(Sender, LogParams)
If LogParams.MessageText = "The window was destroyed during method execution." Then
LogParams.Locked = True
Else
LogParams.Locked = False
End If
End Sub
Hi Ebunny,
I use a similar approach as You do.
There were two issues to solve:
1) how to suppress technical errors e. g. arising while TC is synchronizing with the AUT?
2) how to deal with known application errors and unknown ones?
The approach is:
1) suppress technical errors in the GeneralEvents_OnLogError event handler
2) replace the error message by a warning for known errors, and add a prefix to the title ("Known: ")
3) stop test run on unexpected errors which make it impossible to further execute the test.
My solustion uses a global "ErrorOption" object located in a script extension.
The properties:
.Locked (r/w): the error(s) occurring in this section are pure technical ones and shall be suppressed
.known (r/w): the error to be generated by a checkpoint in a test routine shall be treated as a known one
.hasError (r/w): an error occurred, a known one or a suppressed one
.Routine (r/w), the originator for Logging and debugging purposes
The methods:
ReportError; used in the GeneralEvents_OnLogError event handler to inform the global option object about an error message having been suppressed or changed to type warning. It sets the .hasError property to true
Restore; resets .known, .hasError and .Locked to previous values.
There is not only a single one option object, but there is:
- a basic global one and eventually
- one or more local ones that work together with the global one.
This is necessary to lock and unlock correctly in a test routine hierarchy: e.g. lock errors at a certain location in the upmost test routine, but unlock at a certain location in a called routine on level l, but re-lock at a certain location in a called routine on level, and so on.
There are also two constructor routines:
Function ErrorLock(Routine)
- creates a new local ErrorOption object and links it to the global one, sets .Locked to True
Function ErrorSetKnown(Routine)
- creates a new local ErrorOption object and links it to the global one, sets .Known to True
The usage is as follows:
1) In the system routine, where technical errors can arise, I use (vbs)
On Error Resume Next ' optionally
Set TcErrLock = PVA_0.TcLog.ErrorLock(mcModul & cRoutine)
.. ' protecte code
TcErrLock.Restore
On Error GoTo 0
In some cases, it is required to also use error handling, as runtime errors can result if properties do not deliver the expected object results.
2) In test routines where I expect a known error, I could use
Set LogError = PVA_0.TcLog.ErrorSetKnown(mcModul & cRoutine)
.. ' checkpoints, log.Error, etc here
LogError.Restore
In reality, I do not use this explicitely, because I've got another global helper object for logging, the checkpointList, which does it for me.
Finally, the GeneralEvents_OnLogError event handler queries the global "ErrorOption" object, locks technical errors, replaces known errors by warnings and uses the .ReportError routine to inform the ErrorOption.
Works fine
Kind Regards,
Manfred
