{"id":178,"date":"2005-10-04T13:46:00","date_gmt":"2005-10-04T21:46:00","guid":{"rendered":"http:\/\/spacefold.com\/colin\/morethanfour\/?p=178"},"modified":"2020-08-16T13:49:40","modified_gmt":"2020-08-16T21:49:40","slug":"structured-error-handling-with-newobject-errors","status":"publish","type":"post","link":"https:\/\/spacefold.com\/colin\/morethanfour\/2005\/10\/04\/structured-error-handling-with-newobject-errors\/","title":{"rendered":"Structured error handling with NEWOBJECT errors"},"content":{"rendered":"\n

Marcus wrote a very good article about the TRY-CATCH structured error handling in VFP8 and later versions. One\u00a0section in particular<\/a>\u00a0caught my eye because it directly relates to an issue I’ve hit recently:<\/p>\n\n\n\n

[..] the result is opposite from the previous example. The\u00a0Error()<\/em>event takes precedence over the Try\/Catch and handles the error inside the called object.<\/p>

So what would happen if we added some structured error handling to the\u00a0TestClass\u00a0<\/em>object?<\/p><\/blockquote>\n\n\n\n

\n

DEFINE CLASS TestClass AS Custom
   FUNCTION Execute
      TRY
         xxxxxx
      CATCH
         MESSAGEBOX(“Exception 2!”)
      ENDTRY
   ENDFUNC<\/p>\n\n\n\n

   FUNCTION Error(nError, cMethod, nLine)
      MESSAGEBOX(MESSAGE())
   ENDFUNC   
ENDDEFINE<\/p>\n<\/div><\/div>\n\n\n\n

In this example, the new Try\/Catch\u00a0will handle the error<\/strong>\u00a0since it has been defined at a higher level of granularity.<\/p><\/blockquote>\n\n\n\n

Alas, this is not strictly true for every<\/strong> case. Consider the following code:<\/p>\n\n\n\n

q = newobject(\"myTest\")\nq.Execute()\n\n\ndefine class myTest as custom\n\nprocedure execute\n   try \n      *-----------------------------------------\t\n      * This is handled nicely by the \n      * surrounding TRY_CATCH:\n      *-----------------------------------------\t\n      y = newobject(\"invalidClass\")\n\n      *-----------------------------------------\t\n      * This one ignores the TRY-CATCH and \n      * triggers the .Error() event:\n      *-----------------------------------------\t\n      THIS.NewObject( sys(2015), \"invalidClass\", \"invalidLib.vcx\" ) \n\n   catch\n      =messagebox( \"We successfully caught the error in the catch.\",64  )\n   endtry\nendproc\n\nprocedure error( p1, p2, p3 )\n   =messagebox(\"The object's error() event was triggered instead!\",16)\nendproc\n\nenddefine<\/pre>\n\n\n\n
The structured error handling works as expected for the NEWOBJECT()<\/strong> function call, successfully trapping the “class not found” error. However, the method call THIS.NewObject()<\/strong> will force the objects .Error() event to fire, requiring a completely different set of handling code to suppress the error. This is not a bug, it’s the way objects work. Objects always defer to their own .Error() events to handle errors. Annoying, isn’t it?<\/p>\n","protected":false},"excerpt":{"rendered":"
Marcus wrote a very good article about the TRY-CATCH structured error handling in VFP8 and later versions. One\u00a0section in particular\u00a0caught my eye because it directly relates to an issue I’ve hit recently: [..] the result is opposite from the previous example. The\u00a0Error()event takes precedence over the Try\/Catch and handles the error inside the called object. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24],"tags":[],"class_list":["post-178","post","type-post","status-publish","format-standard","hentry","category-foxpro","post-preview"],"_links":{"self":[{"href":"https:\/\/spacefold.com\/colin\/morethanfour\/wp-json\/wp\/v2\/posts\/178","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/spacefold.com\/colin\/morethanfour\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/spacefold.com\/colin\/morethanfour\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/spacefold.com\/colin\/morethanfour\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/spacefold.com\/colin\/morethanfour\/wp-json\/wp\/v2\/comments?post=178"}],"version-history":[{"count":0,"href":"https:\/\/spacefold.com\/colin\/morethanfour\/wp-json\/wp\/v2\/posts\/178\/revisions"}],"wp:attachment":[{"href":"https:\/\/spacefold.com\/colin\/morethanfour\/wp-json\/wp\/v2\/media?parent=178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/spacefold.com\/colin\/morethanfour\/wp-json\/wp\/v2\/categories?post=178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/spacefold.com\/colin\/morethanfour\/wp-json\/wp\/v2\/tags?post=178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}