Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How to trap errors with ON ERROR while error event in pl
Message
 
To
12/02/2002 12:07:27
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00618670
Message ID:
00618969
Views:
24
>>You can't get ON ERROR to take precedence over an Error method of an object in the program stack. However, you could either move your code into method of a Custom class object, or wrap your UDF with an object, whose Error event method would then be usable for trapping errors as you intend. Even if you leave the code in a UDF and have a method of your wrapper object call it, the wrapper's Error event will catch any errors encountered in the PRG.
>
>To extend Mike's idea, the wrapper class' Error method could look at ON('ERROR') to see what error processing the UDF expected to do, and then explicitly call it. Here's an example:
lparameters tnError, tcMethod, tnLine
>aerror(laError)
>if not empty(on('ERROR'))
>    lcError = upper(on('ERROR'))
>    lcError = strtran(lcError, 'SYS(16)',   '"' + tcMethod + '"')
>    lcError = strtran(lcError, 'PROGRAM()', '"' + tcMethod + '"')
>    lcError = strtran(lcError, ',ERROR()',  ',tnError')
>    lcError = strtran(lcError, ' ERROR()',  ' tnError')
>    lcError = strtran(lcError, 'LINENO()',  'tnLine')
>    lcError = strtran(lcError, 'MESSAGE()', 'laError[2]')
>    lcError = strtran(lcError, 'SYS(2018)', 'laError[3]')
>
>* Call the error handler.
>
>    &lcError
>endif
Doug

Extending your idea a little further, Doug, one could create a generic UDF wrapper (let's call it evalexpr) that takes as its argument an arbitrary VFP functional expression to be evaluated, and returns the result of that evaluation. Evalexpr would just be a wrapper for a generic lightweight object (e.g. call this class CustEval), whose job is simply to evaluate the given expression and return the result back to evalexpr, which in turn returns the result to the original caller. Assuming the CustEval.Error method does something like what you suggested, the net effect would be to "objectify" any ON ERROR handling that goes on in evaluating an arbitrary functional expression.

It's somewhat limited and a bit of a kludge, but this seems like a potentially useful general-purpose remedy to the sticky problem of integrating UDF-style ON ERROR handling with OO-style Error methods.

Mike
Montage

"Free at last..."
Previous
Reply
Map
View

Click here to load this message in the networking platform