UPDATED: Well done Rick for spotting this one! It is considered bad practice to return from a finally block – the behavior of the code is unpredictable, based on the route the code takes and whether an exception is thrown or not. Here’s some further reading on the subject. If an exception must be thrown, the return should happen outside of the try…catch. If the function must return a value, the catch should return a value, for example -1, while suppressing (not throwing) the exception.

Really quick one today! I found this in loads of code at my latest project – can you identify the problem?

function CodeChallenge10()
{
  // Declare variables
  var boContact, bcContact;
  var numContact = 0;

  try
  {
    // Instantiate new BC instance
    boContact = TheApplication().GetBusObject("Contact");
    bcContact = boContact.GetBusComp("Contact");
    with (bcContact)
    {
      // Create query context
      ClearToQuery();
      SetViewMode(AllView);
      ExecuteQuery(ForwardOnly);

      numContact = CountRecords();

      return numContact;
    }
  }
  catch(e)
  {
    // Call the custom LogError function to write error to error log
    LogError("Woops, an error has occurred!");
  }
  finally
  {
    // Destroy objects
    bcContact = null;
    boContact = null;
    return numContact;
  }
}

Answers below, please!

UPDATED: Well, Ranjith wins again! ForwardBackward removes duplicates from the record set returned while ForwardOnly does not. As such, if there’s a dodgy join in the BC, which returns more than one record, then the record counts will actually differ. This type of issue raises it’s head when traversing record sets in code using ForwardOnly, having seen what should be the same record set in the UI – however, Siebel uses ForwardBackward to populate applets, so the records seen may be different. Nice one Ranjith!

An interesting one today. I came across this while debugging an issue and it revealed something about some Business Component methods that I didn’t know. I’ve been in the Siebel business for nearly 13 years and I’m still learning! Note that this is a bit of an ‘odd’ one and you may need to open your mind a bit as to how I’ve presented it.

function CodeChallenge6(Inputs, Outputs)
{
  // Declare variables
  var boContact, bcContact;
  try
  {
    // Instantiate new BC instance
    boContact = TheApplication().GetBusObject("Contact");
    bcContact = boContact.GetBusComp("Contact");
    with (bcContact)
    {
      // Create query context
      ClearToQuery();
      SetViewMode(AllView);
      ExecuteQuery(ForwardOnly);

      Outputs.SetProperty("NumRec1", CountRecords());
    }

    // This does the same thing
    with (bcContact)
    {
      // Create query context
      ClearToQuery();
      SetViewMode(AllView);
      ExecuteQuery(ForwardBackward);

      Outputs.SetProperty("NumRec2", CountRecords());
    }
  }
  catch(e)
  {
    // Call the custom LogError function to write error to error log
    LogError("Woops, an error has occurred!");
  }
  finally
  {
    // Destroy objects
    bcContact = null;
    boContact = null;
  }
}

Answers below!