Wiki Home

Try Catch Finally Usage


Namespace: WIN_COM_API
Knowing when to use a Try Catch Finally block can be a tough concept to grapple with. There is a guiding principle you can use to easily identify an appropriate TRY-CATCH opportunity in your Visual FoxPro code:

TRY-CATCH Usage Principle

If an exception can be handled by a means other than generic exception handling code, then handle it in a TRY-CATCH block.

Examples

There are external software interfaces and interactions where you are not guarenteed control, such as:
In each of these instances, the external systems or internal processes based on uncontrollable data source (e.g. divide by zero) can be handled gracefully and predictibly with code beyond the scope of generalized error handling. This reality makes these good candidates (although not guarenteed candidates) for TRY-CATCH.

Thinking about the design of your code and classes will help you to determine how and where to handle the exception caught in the TRY-CATCH. For instance, when handling the failed ODBC connection, what does the calling routine do when the code responsible for making the connection finds it cannot connect? In other words, how dependent is your system on the ODBC connection? What features of your program will and will not work? Can the user accomplish useful work without the ODBC? If yes, then the system ought to recover back to a place to allow the user to continue using the features independent of ODBC. Otherwise, the system needs to inform the user and close out gracefully.

This last reality of determining what features will work Vs those that will not presents a great place to consider how modular your system code is. Good modularity will facilitate good TRY-CATCH use and results. Poor modularity will still allow you to use TRY-CATCH, but will limit the benefits you're code will have to your end-users for what are hopefully obvious reasons.
Can someone throw some light on THROW, to me it is integral to a TRY-CATCH, please correct me if I am wrong
I think you're right about this. Blissfully ignored errors can be insidious. -- Steve
TRY
   *** My Code that can fail due to outside influence
CATCH TO loErr
   IF loErr.ErrorNo = xxx
      MESSAGEBOX(...)
   ENDIF
   *** all other errors blissfully ignored
ENDTRY


TRY
   *** My Code that can fail due to outside influence
CATCH TO loErr
   IF loErr.ErrorNo = xxx
      MESSAGEBOX(...)
   ELSE
      THROW
   ENDIF
ENDTRY


NOTE: THROW is ignored by a CATCH-WHEN construct. Beyond this constraint, it seems very sensible to include the construction of IF-ELSE together with THROW because the stated premise of handling known potential errors gracefully, does not mean this is the only error that could happen (see InsecurityByDesign). Therefore, we do need to CATCH a potentially known error and THROW when that specific error(s) is not the one caught.

See also two excellent articles: Throw Exception and Throw Exception Revisited
( Topic last updated: 2009.12.05 09:11:57 PM )