On 17 Jul 2017, at 5:07 am, Robert Livingston via 4D_Tech <4d_tech@lists.4d.com> wrote: > > On Jul 14, 2017, at 5:10 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> > wrote: >> >> I was just consolidating some old code and ran across something that I >> wrote some time back called Set_Exists. No clue. It seems to work, but I >> can't say why. > > No clue?? I cannot say why?? I am not sure whether this is a joke that I > don't get or what. > > It would seem to be fairly clear that the basic logic here is to use the > > Is in set() Command to test for whether a set exists. The documentation > says that if a set does not exist, then this will throw an error. So the code > is taking advantage of this
Hi Robert Are you able to provide a link to where the documentation states this? > Then he asks us to confirm if the code is reliable. But there are three > methods included in the code > > ErrorHandler_Install > ErrorHandler_SuppressError > ErrorHandler_InstallPrevious > > that we are not given. How am I supposed to test it? I think David is asking us to confirm whether trapping for an error on "Is in set" is a reliable means for determining whether the set exists. It "seems ok" but I wasn't able to find the 4D documentation that asserts that an error is thrown if the set doesn't exist. I don't think he necessarily wants us to run his code as provided, although given the pretty descriptive names of those methods it's not to hard to work out what they do. > Now I assume that from the names of these methods that basically that if an > error occurs that > > ErrorHandler_SuppressError is called and that this method turns the process > variable Error to a number other than zero and that is how you figure out > whether the error was thrown and thus whether > > Is in set() threw an error. To be fair the Error process variable is a built-in 4D system variable so it would be 4D that is setting its value rather than David's error handler. I suspect David's method could actually contain nothing, although knowing him it probably contains some sort of logging. That said, 4D do suggest copying the Error variable into your own process variable if you need to reference it outside of the error handler method: http://livedoc.4d.com/4D-Language-Reference-16-R3/Interruptions/ON-ERR-CALL.301-3217504.en.html > For those who might have been confused in the fashion that I was, I would > offer this version of what I think David's code is that I think is clearer. > You might disagree: > The method "ErrorIgnore" sets a inter-process variable (<>fErrorHappened) to > True I don't know that the code is necessarily clearer but I would strongly discourage the use of an interprocess variable here. You could end up with an impossible to debug situation where two or more processes are updating/reading the state of this interprocess variable. Error handling is process-specific so should really use process-level variables. Cheers J ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
