Forum Discussion

RUDOLF_BOTHMA's avatar
RUDOLF_BOTHMA
Community Hero
6 years ago

Exception handling good practice in Jscript

Hi all,

 

I recently posted a question regarding how to capture the call stack so I can output it to the log when something goes wrong.  What I did discover though is that that's not actually what I should have been asking :smileytongue:

 

If you are interested:

 

Previous question

 

Now on to the current question.  What is the best way to do robust error handling of try..catch.. using Jscript.  I have an OO background (c#) so naturally tend to go down that route when trying to solve an issue.  That isn't always the right solution for scripting languages though.  From the previous post:

 

function Scriptcall1()
{
  try
  {
    LogErrorStack1();
  }
  catch(e)
  {
   switch(e)
   {
    case "1":
    Log.Message("This isn't serious, just continue");
    break;
    case "2":
    Log.Error("This is very serious");
    break;
   }
  }
}

function Scriptcall2()
{
  try
  {
    LogErrorStack1();
  }
  catch(e)
  {
   switch(e)
   {
    case "1":
    Log.Error("This is very serious this time");
    break;
    case "2":
    Log.Message("This isn't serious this time");
    break;
   }
  }
}

function LogErrorStack1()
{
  try   
  {
    LogErrorStack2();
  }
  catch(e)
  {
    throw e;
  }
}

function LogErrorStack2()
{
  try
  {
    throw("1");
    // or throw("2");
  }
  catch(e)
  {
//***** Here is the actual question I should be asking: ********
    LogException(e,"Perhaps you should try that again"); //But I don't want this to error. I  want to re-throw the exception to the top level function and let that decide if it's a serious problem
    throw e;
  }
}

As you can see, my outlook is to equivalently re-throw an exception up the chain until it reaches a function that knows what to do with it and whether to catch and throw or catch and continue.

Case "1"; Case "2" isn't ideal either, since it leaves an opening for a new "Exception" type to be added down the road that is then not handled.  How do you handle this ?  One of the ideas I'm thinking of is to build a custom exception "class" which is just a KVP with Exception Types which I define in an enum as key and call stack as value.  Can you throw this ?  I'm all ears to hear what you think of my attempts.

11 Replies

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3

    Hi,

     

    Personal private opinion based on the projects I participated in:

    a) TestComplete provides call stack in the Call Stack log pane. I think that the provided call stack is good enough and is bound to the test code making it possible to navigate to code from call stack. At the same time I don't see any good reason to post a full call stack to the test log itself because test log should be compact, readable and understandable for non-programmers (like manual testers or managers). Thus I don't see the reason in getting call stack from exception.

     

    b) The only case when exceptions were useful in test code was for web services testing when the service was called with incorrect parameters in order to get the 4xx return code. In all other cases the called function either reported a problem or returned an indication of success/failure processed by the calling code as required. This was always possible because, by definition, test code always perform defined action to verify defined behaviour and thus always know expected code call result. In case test code fails because of unexpected situation (e.g. when attempting to write to a read-only file), then it is perfectly fine if the code fails. This reveals but not hides the code problem which can be immediately addressed. If it is possible that the given file can be read-only, then test code must be improved to make file writable before writing to it. If the file must not be read-only, then test code must be improved with verification block and clearly report a problem to the test log.

     

    • shankar_r's avatar
      shankar_r
      Community Hero

      AlexKaras wrote:

      a) TestComplete provides call stack in the Call Stack log pane. I think that the provided call stack is good enough and is bound to the test code making it possible to navigate to code from call stack. At the same time I don't see any good reason to post a full call stack to the test log itself because test log should be compact, readable and understandable for non-programmers (like manual testers or managers). Thus I don't see the reason in getting call stack from exception.

       


      Rightly pointed out, As far as automation script error call stack concerns TestComplete call stack on log pane is the best place to see. What  RUDOLF_BOTHMA  trying is looking to be complicated. I don't think we need to have this complicated logic for automation scripts. In my view, most of the run time error occurs can very well be identified during our test runs which we can cover before running against AUT. Also, most of the error during execution related to the object identification/timing issue which try...catch can't catch. 

      End of the day, automation should verify AUT without any false positive and if there is any failure a good framework and standard scripting will help to identify the issue. There will be a nightmare in every script where/how that failed that will be a happy headache to take and resolve by trying various scenarios.

      • AlexKaras's avatar
        AlexKaras
        Champion Level 3

        shankar_r wrote:

        Also, most of the error during execution related to the object identification/timing issue which try...catch can't catch. 

        Yes, absolutely valid and correct point.