Thank you Phil. That is basically what I am doing. My test for exception is in a Common unit that gets included in all of my other units. It looks like this:
// Tests whether an exception has occurred since Testcomplete does not handle this correctly.
// Returns true if res in a real or fakie exception. Sets Common.tErr to the error.
function isException(res) {
var objType = Object.prototype.toString.call(res);
// Workaround to handle errors from EventHandlers. EventHandlers do not return values or exceptions.
// Eventhandlers set the values in Common.err when they have an exception.
if (Common.err!=null) { // Common.err is set in EventHandlers.
Common.tErr = new Error(Common.err.number,Common.err.message);
Common.tErr.name = Common.err.name;
Common.err = null; // Set it to null for the next trap.
return true;
}
if (res==null)
return false;
if (objType!="[object Object]" && objType!="[object Error]")
return false;
// Workaround to handle JScript errors from external units.
// Do not override the name property if you create a new type of error.
if (res) {
if (res.hasOwnProperty("name") || aqObject.IsSupported(res, "name")) {
if ( res.name=="Error"
|| res.name=="EvalError"
|| res.name=="RangeError"
|| res.name=="ReferenceError"
|| res.name=="SyntaxError"
|| res.name=="TypeError"
|| res.name=="URIError"
) {
Common.tErr = new Error(res.number,res.message);
Common.tErr.name = res.name;
return true;
}
}
if (res.hasOwnProperty("isError")) { // Add isException to all custom Errors so they get trapped.
Common.tErr = new Error(res.number,res.message);
Common.tErr.name = res.name;
return true;
}
}
// Handle errors local to Common.
if ( res && res instanceof Error) {
Common.tErr = res;
return true;
}
return false;
}
function testIsException() {
var res;
Log.Message(isException(res));
Log.Message(isException(null));
Log.Message(isException("string"));
Log.Message(isException(1));
Log.Message(isException({}));
Log.Message(isException(new Error()));
Log.Message(isException(new SyntaxError()));
}
I looked into Delphiscript and decided not to use it. It isn't object oriented, and I wanted something OO to make it easy to do GUI mapping. To do OO I would probably need to misuse ODT, which would have introduced its own clunkiness.
I believe VBScript is more cumbersome that JScript for exception handling, even with the clunky JScript trap() function wrapped around everything that could throw an exception. I do not want to use VBScript.
I looked at ways to use high level languages like Java. TestComplete does allow some access as Connected Applications. If Java worked well with COM I might have used it. I don't think my QA department can hire good experienced high level language staff right now. So I ruled out that approach.
I'm going to stay with JScript even though it breaks the gracefullness of my design by making me put the silly looking trap() function around most of my test statements. It seems to be the least worst approach.
