When to Use Exceptions

If the error is something that you can easily check, you shouldn't use exceptions. For example, suppose your page had begin and end date fields. In your SavePreChange PeopleCode program, you would want to check to verify that the end date was after the begin date. This kind of error produces incorrect data. It doesn't terminate your PeopleCode program. This is a simple check, one that you don't need to throw an exception for.

Errors that you might want to use exceptions for are the kinds that you are going to check for often. If you do not want to catch a specific exception, but any general exception, then a simple try-catch block is all that is required. Just write code to catch the general Exception object. For example:

try
  &RETCODE = GetAttachment(&IB_ATTACH_REC, &SOURCEFILENAME, &SOURCEFILENAME, "PS_FILEDIR");
catch Exception &err
  &RETCODE = GetAttachment(&IB_ATTACH_REC, &SOURCEFILENAME, "/files/" | &SOURCEFILENAME, "PS_SERVDIR");
end-try;

However, it might make more sense to have a single exception class for that kind of error, so you'd only have to write your error handling code once. For example, suppose that a function you called was supposed to return an array object that you'd then manipulate using the array class methods and properties. When the function fails and doesn't return an array object, you can either check for null, or check for an exception (as this kind of error terminates your PeopleCode program). If you must often check for nulls, perhaps instead of constantly checking, you could rely on the runtime system throwing exceptions for you.

The following provides a pseudo-code example:

import MYAPP:Exception; 
/* This subpackage contains all the exception classes for your app */

try 
   &MyArray = GetArrayData(&Param1, &Param2, &Param3);
   /* Code to manipulate &MyArray here */

catch ExceptionNull &Ex1
   if &Ex1.MessageSetNumber = 2 
      and &Ex1.MessageNumber = 236 Then 

   /* This is the message set and message number for &MyArray being Null */ 

   /* do data error handling */

   end-if;
end-try;

Considerations Using Exceptions and Transfer Functions

Using functions that transfer the end user to a new component, such as the DoModal, DoModalComponent, or Transfer functions (in some cases) inside a try-catch block do not catch PeopleCode exceptions thrown in the new component. Starting a new component starts a brand new PeopleCode evaluation context. Exceptions are caught only when exceptions thrown within the current component.

In the following code example, the catch statement only catches exceptions thrown in the code prior to using the DoModal function, but not any exceptions that are thrown within the new component.

/* Set up transaction */
If %CompIntfcName = "" Then
   try
      &oTrans = &g_ERMS_TransactionCollection.GetTransactionByName(RB_EM_WRK.DESCR);
      &sSearchPage = &oTrans.SearchPage;
      &sSearchRecord = &oTrans.SearchRecord;
      &sSearchTitle = &oTrans.GetSearchPageTitle();
      If Not All(&sSearchPage, &sSearchRecord, &sSearchTitle) Then
         Error (MsgGetText(17834, 8081, "Message Not Found"));
      End-If;
      &c_ERMS_SearchTransaction = &oTrans;
      
      /* Attempt to transfer to hidden search page with configurable filter */
      &nModalReturn = DoModal(@("Page." | &sSearchPage), &sSearchTitle, - 1, - 1);
   catch Exception &e
      Error (MsgGetText(17834, 8082, "Message Not Found"));
   end-try;