Nested try/catch - have used them yet?

If you have not used try/catch blocks, don’t be surprised - you do have company. Even to this day and age when Siebel has become a really make sure application over a decade ( without any significant changes for the better part of the decade I might add), there are developers who simply skip this.

Yes, design reviews will catch these instances. But, I know of implementations that do not undergo the design review process at all (horror!).

The premise of a try/catch block is simple. You try to catch all the errors that is possible in your script, handle those errors in the catch block, and finish off in the finally block.

Function IamAFunction
{
try {
   var boAccount = TheApplication().GetBusObject();
   // do something awesome
}

catch(e) {
   throw (e);
}

finally {
  boAccount = null;
}

This is fairly easy to understand, and is derived from ECMAScript.

Even at the cost of increasing the number of lines of code, I recommend a try/catch block in all the functions that you will ever code. Even if that does not make sense today, believe me, it makes absolute sense in the next year when you are enhancing the code.

If you find throw() to be quite elaborate , consider using TheApplication().RaiseErrorText. Or, do not do anything in catch block. This clearly tells a developer who is debugging the code that is it is a deliberate attempt to suppress errors.

It is indeed a common enough practice to handle the errors in the called function, and provide a specific return value to the caller rather than to “raise” the error to the next level.

No, we did not digress. The same principle can be applied within a single function.

You can nest try/catch blocks to handle the error within the inner block and continue processing in the outer block as if nothing happened.

Consider the below piece of code.

Function IamASuperFunction
{
try {
   var boAccount = TheApplication().GetBusObject();
   // do something awesome

   try {
       TheApplication().RaiseErrorText("Sadly, I'll never reach any of the outer worlds.");
   }
   catch(e){
       // do nothing
   }

   //continue awesomeness
}

catch(e) {
   throw (e);
}

finally {
  boAccount = null;
}

The error in the inner block will never really be shown to the outer catch statement, and will not impact any code in between.

This is useful when -

You’re trying to perform operation in a loop and want to read more all errors in that loop. ( in real-world you want to log it somewhere and not completely ignore that)
You are calling a OOB service that returns an error when criteria is not satisfied, and you want to handle that error differently. For example this happens quite a few times while doing RegEx operations.
You’re calling a custom function, but you do not want to fail the caller script because of the error in called function
For some strange reason you’re trying to institute operations in batch in a single service, and do not want to fill the entire batch because of failure in one of the records

Now, ain’t that useful?

Bonus: you can do the same thing in workflows by just connecting red lines from each of the steps to the “End” step. All errors are swallowed painfully, and everyone seems to be happy at the outset.

Recent Articles