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
