Error handling using VBScript
I have recently amended the framework that we use for our UFT automation tests. I have moved to a more modular function based framework, where code can be recycled better, hopefully reducing our maintenance overhead.
However I have a number of problems with error handling when using a lot of functions (stored in functional libraries).
No visible stack trace.
in a scenario where Action A function1 function2
If we get an error in function2 I cant find out the calls that were made to identify where the error is.
Err.number and Err.description are blank when recovery scenario is called.
I'm guessing this is due to UFT behind the scenes running err.clear or something.
But every time I try to get the err.details from a function called by a recovery scenario it is blank.
Lots of people appear to use on error resume next.
Surely the point of error handling is to handle errors when they are not expected.
Using on error resume next and having an if statement checking for err.number at a set point only returns the error details there.
You would need it on every line to trace all errors.
So then to the questions:
1. Am I missing something obvious from my logic?
2. Do you know any good solutions around VBScript error handling.
Are you talking about 'error trapping' within the script or script debugging post error or failure?
I use a global logging object that writes all pertinent info to a log irrespective of where you are in the function calling chain. tailing the log at runtime also gives give clarity of where the script execution is up to which is good for timing the coffee runs
The only reliable mechanism I've seen, is to include a call to an error handling function at the bottom of every single function you write.
It allows a tiny tiny TINY bit of half @rsed stack trace by allowing you to tell the error handler what you were doing last...
On Error Resume Next ' if an error is raised, go on to "the next thing", which in this case is a call to our error handler
' all my code for this function
If Err.number <> 0 Then
' code to report the error description and source
If Not IsNull(raisedFrom) Then
' we know the error was thrown from one of our functions and we can report it
' The error came from raisedFrom
On Error Goto 0 ' we've handled the error, we can reset the error object now
... just another Tester ...
@Alex...If an error occurs in "'all my code fo rthis function" will QTP go through the rest of the lines of code before reaching MyErrorHandler? If something is broken and QTP keeps moving along, can it be making more damage until it finally hits the function call?
Another part of Error handling that I think is awful is that many of the EXIT functions do not work inside of a library.
For example EXITACTION and EXITACTIONITERATION do not work from inside of an action.
This has been broken up to at least 11.52. I don't know about 12.0.
Short Answer: Yes.
Originally Posted by bklabel1
To be more precise you would have to place the call to your error handler after every single line that may thrown an error.
There's a comment in the ALM11.5 VAPI-XP vbscript template which makes the same point:
' *** VBScript Limitation ! ***
' "On Error Resume Next" statement suppresses run-time script errors.
' To handle run-time error in a right way, you need to put "If Err.Number <> 0 Then"
' after each line of code that can cause such a run-time error.
... just another Tester ...
What sort of errors are you encountering and what do you want to do with them?
I've never encountered a real need for error handling in qtp. Most of the scripting errors are found in the process of writing the script. Things that come up after the fact are usually related to application changes of some sort.
Maybe it's just me but if a test encounters an error I just want it to stop and the info written to the log by default is usually enough to debug the source of the problem. Though I always used a pretty protected interaction with the application. Before every input I always check exist/ready/visible/etc through a common function. So the "error" handling there is just reporting to the log that the object did not exist. Then I'm nested in such a way that the test can continue where appropriate and exit if it was a critical piece.
you are correct there is no visible stacktrace, and there is alog of On Error Resume Next, Err.Clear(), On Error GoTo 0, over and over again. VBScript is one of those languages I've worked with which I think seriously needs to die.
Here's my advice..
Setup a framework.
1. As part of the framework create an error handler (which logs the error to some global variable or 'Environment' variable),
2. A Function for pushing and popping the current context to a pseudo stack.
When you do On Error Resume Next, make sure you turn it back off and clear it before exiting a subroutine or function. Make sure to do all you logging and exception handling and management before you exit the function.
Have everything always return some value. For example, I always have it return a null if there's an error, and a true or value if it succeeds. That way functions upstream can switch on it.
That said. QTP and many other test tools were designed with a simplistic idea that 1 test = 1 script, and built around the record and playback idea. In that paradigm each test is basically 1 continuous script which is generated by the record and playback. VBScript has the limitation as it was designed as a task automation language, not a full programming language. So you may have to weigh the idea of manageability of designing a framework with reusable pieces that may contain several call layers vs. a flat design where your test scripts shares very little code. I've done heavy custom frameworks in QTP and TestComplete, and I've scratched my head to as if the amount of error handling and framework code was even worth it.
Last edited by dlai; 07-18-2014 at 09:35 AM.