VERSIONS: All, written for Paradox 5
SUBJECT: errorTrapOnWarnings()
BY: MARK PAUKER
I don't want to re-ignite the "Great Error Handling Debate," but just to refresh your memory.
I believe that there was a general consensus that errorTrapOnWarnings is something to stay away from. The problem is that the effects of this method are scoped in a way as to not make it _very_ difficult to use effectively.
In terms of the actual strategies being described, I presented an exception-based handler (similar to the one in Delphi) where each "fatal" error issued a fail(). This seemed to me to be the easiest, most straightforward way of dealing with errors as they arise.
Henrik Bechman, on the other hand, professed a notification-based error handler, where each method would return True/False. This methodology is more in line with Paradox's native error handler. Henrik liked the more "natural" way that errors flowed through the system, without having to be handled only as "exceptions."
Again, not wanting to rekindle the flames, let's just say that both methodologies have strengths and weaknesses. The main thing that we both agreed on was the basic concept that the return codes of all RTL methods and rocedures (that return True/False) need to be checked and dealt with appropriately.
If you are going to use try/onFail (which is my preferred methodology), then you need to issue a fail() when you encounter a "fatal" error. On the other hand, if you wish to return False when you encounter a failure (Henrik's preferred methodology), then you need to propagate that failure all the way up (by continuing to return False) until you get to the top of the calling chain.
FROM: KEVIN
You are indeed correct about errorTrapOnWarnings. In my little reality I stopped using this method in favour of forcing 'fail' from within a chunk of code. Something like this:
method blahblah(...)
if abc.open( ...) then
;; do stuff as you need.
else
fail( UserError + someConst,
"Abc didn't open and I say we don't proceed.")
endIf
endMethod
The benefit of this approach is that you never accidentally leave errorTrapOnWarnings on...which can be catastrophic. And you still take control of
the execution in critical situations...that is, situations that your application deems critical.
As a rule don't use errorTrapOnWarnings...it will come back to haunt you if you miss turning it off sometime.