[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Feature -catchstop 1 is a tech preview in 11.7.x ...

[dbeavon]

Thanks for explaining the reasoning behind the two variations of STOP (Progress.Lang.Stop and Progress.Lang.StopError). Below is a screenshot from the docs I suppose I can see the risk in allowing the existing catch blocks to start catching new types of problems like lock-conflicts, stop-after, etc. But I'd say an ABL developer should expect the change in behavior because (1) they were the ones who had determined to catch the *generic* Progress.Lang.Error in the first place... be careful what you ask for because you might get it ... , and (2) it is at their own discretion to switch over to using "-catchStop 1" (at least for as long as they are on OE 11.7.x) The model I use in my head for S.E.H. error-handling puts "Progress.Lang.Error" in a special place. I think of it as being sufficiently generic that it catches almost anything that can go wrong, (short of unplugging the computer, or kill -9, or running out of RAM). It seems like that should be especially true for problems which are self-inflicted because of the design of the logic or the configuration of timeouts (stop-after timeouts, lock-conflict timeouts, etc). Going forward, I will have to remember that "Progress.Lang.Error" isn't sufficiently generic to catch timeouts (stop-after or lock-conflict). Maybe OE will need to come up with a new "catch-all" interface that combines the "Progress.Lang.Error" with "Progress.Lang.Stop". Today in my entry-level appserver procedures, I already have to use repetitive code to catch Progress.Lang.Error and subsequently convert to "RETURN ERROR" statement for marshalling over to a .Net openclient. Now that Progress.Lang.Stop has arrived, I will also be forced to catch these new errors in many situations as well, making the code in the entry-level procedures even more repetitive. Perhaps I will have to go back to using compile-time include, eg. {Includes/RepetitiveCatchBlock.i}. As a side note, the STOP condition does get marshalled to the .Net openclient already (for free) but I don't believe that the .Net side can distinguish a LockConflict from another type of STOP.

Continue reading...