Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Structured Error Handling in VFP 8 : Page 5

With the introduction of Visual FoxPro 3.0, error handling in VFP changed substantially. Rather than using "on error" statements, "state of the art" error events became available. Now, seven years later, more sophisticated error handling mechanisms take center stage as Visual FoxPro 8.0 introduces structured error handling.


advertisement

Mixing Error Handling Methodologies
Structured error handling is great and will replace traditional error handling in most scenarios. In fact, some modern languages like C# have only structured error handling. However, there are some downsides to structured error handling, such as no intrinsic retry capability. Also, in many scenarios, pre-existing, non-structured error handling may be in place.

So let's look at a few examples of mixed error handling and the effects it may have on your code. Let's start out with a simple one:

   TRY
      ON ERROR MESSAGEBOX(MESSAGE())
      xxxxx
      ON ERROR
      xxxxx
   CATCH
      MESSAGEBOX("Exception!")
   ENDTRY
In this example, we define an ON ERROR statement within a Try/Catch block ("xxxxx" always represents some kind of error in these examples). What would we expect to happen here?

Most people I present this to would expect the ON ERROR to handle the first problem, and the Catch block to handle the second error. This is not the case! The Catch block takes precedence over the ON ERROR and handles both exceptions.

At this point, you may wonder why one would ever define an ON ERROR inside a Try/Catch. In real-world environments, this is a rather common scenario. Consider this example:

   TRY
      ErrTest()
   CATCH
      MESSAGEBOX("Exception!")
   ENDTRY
   FUNCTION ErrTest
      ON ERROR MESSAGEBOX(MESSAGE())
      xxxxx
   ENDFUNC
The Try/Catch wraps a simple call to another function (or method). That function apparently has its own error handling using the old ON ERROR methodology. However, the local error handling mechanism used by that function is now taken hostage by our Catch block. As you can imagine, this may result in some surprising behavior.

We can produce a similar example using the Error() method:



   TRY
      oTest = CREATEOBJECT("TestClass")
      oTest.Execute()
   CATCH
      MESSAGEBOX("Exception!")
   ENDTRY
   DEFINE CLASS TestClass AS Custom
      FUNCTION Execute
         xxxxxx
      ENDFUNC
      FUNCTION Error(nError, cMethod, nLine)
         MESSAGEBOX(MESSAGE())
      ENDFUNC   
   ENDDEFINE
In this example, we are also calling another method that has a local error handler. However, this time the result is opposite from the previous example. The Error() event takes precedence over the Try/Catch and handles the error inside the called object.

So what would happen if we added some structured error handling to the TestClass object?

   DEFINE CLASS TestClass AS Custom
      FUNCTION Execute
         TRY
            xxxxxx
         CATCH
            MESSAGEBOX("Exception 2!")
         ENDTRY
      ENDFUNC
      FUNCTION Error(nError, cMethod, nLine)
         MESSAGEBOX(MESSAGE())
      ENDFUNC   
   ENDDEFINE
In this example, the new Try/Catch will handle the error since it has been defined at a higher level of granularity.

An interesting question here is, "What happens if that Catch block re-throws the error?"

   DEFINE CLASS TestClass AS Custom
      FUNCTION Execute
         TRY
            xxxxxx
         CATCH TO oEx
            MESSAGEBOX("Error!")
            THROW oEx
         ENDTRY
      ENDFUNC
      FUNCTION Error(nError, cMethod, nLine)
         MESSAGEBOX(MESSAGE())
      ENDFUNC   
   ENDDEFINE
In this example, the Error() method will get a chance to handle the re-thrown error. The outer error handler will not have the opportunity to handle the exception, because it is not possible to elevate the error from within the Error() method because the exception object is not available there. The only option would be to throw a custom error.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date