R
Rob Straight
Guest
Introduction Progress has gotten several requests recently to have an ABL mechanism for trapping error messages associated with STOP conditions. After investigating this from several angles, we have come up with the following proposal and we'd like your feedback. Please note: This feature is currently not planned for any specific OpenEdge release or time frame. Implementation of this feature as described below will introduce a change in behavior in your existing OpenEdge applications. Any CATCH block you have for either Progress.Lang.Error or Progress.Lang.SysError will now also catch most Stop conditions (the ones with error messages). Proposal We would introduce 2 new built-in objects: Progress.Lang.StopError (aka P.L.StopError) This object would inherit from Progress.Lang.SysError and implement Progress.Lang.Error. This would be associated with any STOP condition that has error messages. Progress.Lang.Stop (aka P.L.Stop) This object would inherit from Progress.Lang.Object. This would be generated by the STOP statement, CTRL-C, or a timeout from STOP-AFTER. When possible there will be a property in P.L.Stop that indicates what caused the STOP condition. You would be able to code CATCH blocks using either of these new object types. Existing CATCH blocks will experience a change in behavior because P.L.StopError implements Progress.Lang.Error and inherits from Progress.Lang.SysError, so that any CATCH block you have for either of these will now also catch most STOP conditions as well (the ones with error messages). Note that you must recompile your code in order to experience this new/changed behavior. STOP conditions still bubble up by default just as they do today. If there is a CATCH block that can catch P.L.StopError or P.L.Stop, a STOP condition that occurs many levels down the call stack will bubble up and be caught by that CATCH block (if there are no intervening ON STOP directives that trap it). ON STOP block directives will work just as before. However, if there is a CATCH block on a block that also has an ON STOP directive, the CATCH block will take precedence (Just as CATCH blocks do today on blocks with ON ERROR directives). There are many STOP conditions that today force execution to bubble up to the top of a transaction or even to a level that is above any database connections. With any such condition, ON STOP directives are ignored until that safe level is reached. This will still be true, and now any relevant CATCH blocks may also be ignored until the safe level is reached. Questions 1. Is it a good thing that a CATCH for Progress.Lang.Error (etc.) can catch STOP conditions associated with error messages? Is this what you would expect, or would you rather have to code explicitly to catch any STOP condition? 2. Do you see an issue in that STOP can possibly get caught before it would have before, which is either never caught or at a DO ON STOP higher up the call stack? 3. Is there anything else that OpenEdge Engineering should consider?
Continue reading...
Continue reading...