SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 9 of 9
  1. #1
    New Member
    Join Date
    Jul 2014
    Posts
    6
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Error handling using VBScript

    Hi,
    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).

    Issue 1:
    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.

    Issue 2:
    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.

    Issue 3:
    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.
    Thanks

  2. #2
    Moderator
    Join Date
    Sep 2001
    Location
    Doncaster, UK
    Posts
    5,788
    Post Thanks / Like
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0
    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

    Mark Smith.

  3. #3
    Advanced Member
    Join Date
    Aug 2004
    Location
    Wellington, New Zealand
    Posts
    797
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0
    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...

    Function one(...)
    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

    MyErrorHandler("function one")
    End Function

    Function MyErrorHandler(raisedFrom)
    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
    End If
    On Error Goto 0 ' we've handled the error, we can reset the error object now
    End If
    End Function
    Regards,

    Alex
    ... just another Tester ...

  4. #4
    SQA Knight bklabel1's Avatar
    Join Date
    Sep 2012
    Location
    Kew Gardens, United States
    Posts
    2,596
    Post Thanks / Like
    Blog Entries
    1
    Mentioned
    2 Post(s)
    Tagged
    2 Thread(s)
    Total Downloaded
    0
    @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?

  5. #5
    SQA Knight bklabel1's Avatar
    Join Date
    Sep 2012
    Location
    Kew Gardens, United States
    Posts
    2,596
    Post Thanks / Like
    Blog Entries
    1
    Mentioned
    2 Post(s)
    Tagged
    2 Thread(s)
    Total Downloaded
    0
    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.
    Thanks,
    Kevin

  6. #6
    Advanced Member
    Join Date
    Aug 2004
    Location
    Wellington, New Zealand
    Posts
    797
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0
    Quote Originally Posted by bklabel1 View Post
    @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?
    Short Answer: Yes.

    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.
    Regards,

    Alex
    ... just another Tester ...

  7. #7
    SQA Knight
    Join Date
    Jun 2008
    Posts
    2,555
    Post Thanks / Like
    Mentioned
    3 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0
    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.

  8. #8
    SQA Knight
    Join Date
    May 2006
    Location
    Playa Del Rey, California, United States
    Posts
    2,594
    Post Thanks / Like
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0
    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 10:35 AM.
    David Lai
    SDET / Consultant
    LinkedIn profile

  9. #9
    Moderator
    Join Date
    Sep 2001
    Location
    Doncaster, UK
    Posts
    5,788
    Post Thanks / Like
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0
    Nice peice David.

    Mark.

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 10.00%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 04:07 AM.

Copyright BetaSoft Inc.