background image
<< Exceptions - Programmatically logging an error | Exceptions - Prerequisite >>
Exceptions - Enabling fault trapping
<< Exceptions - Programmatically logging an error | Exceptions - Prerequisite >>
User's Guide
9 H
Enabling fault trapping
TestVerification (STRING sExpected, STRING sTestValue)
if (sExpected == sTestValue)
Print ("Success!")
raise 1, "{sExpected} is different than {sTestValue}"
print ("Exception number is {ExceptNum()}")
The TestVerification function tests two strings. If they are not the same, they
raise a user-defined exception using the raise statement.
The raise statement takes one required argument, which is the exception
number. All built-in exceptions have negative numbers, so you should use
positive numbers for your user-defined exceptions. raise can also take an
optional second argument, which provides information about the exception;
that information is logged in the results file by the built-in recovery system or
if you call ExceptLog.
In the preceding testcase, raise is in a do...except statement, so control
passes to the except clause, where the exception number is printed, then the
exception is reraised and passed to the recovery system, which handles it the
same way it handles built-in exceptions.
Here is the result of the testcase:
Testcase raiseExample - 1 error
Exception number is 1
yyy is different than xxx
Occurred in TestVerification at except.t(31)
Called from raiseExample at except.t(25)
Note that since the error was reraised, the testcase failed.
Enabling fault trapping
Under Windows you can have SilkTest trap system errors (general protection
faults). This means that if the application under test crashes, SilkTest can
raise an exception, record information about the system's state, close the
application, then continue executing your tests.
You enable fault trapping by setting various Agent options. For more
information on the available options, see "Compatibility options" on
page 471.