As this new feature may have potential implications for existing applications when enabled, I'd like to use this channel here as well to draw your attention to this topic. We're planning to release this new feature at the beginning of next week. This is the excepted from the draft of the release notes:
Title: Ability to distinguish STOP and STOP-AFTER
We have now introduced the ability to distinguish between different types of STOP conditions. This feature is based on the ABL's capability to treat STOP conditional more like errors using the constructs of structured error handling. See https://docs.progress.com/bundle/openedge-whats-new/page/STOP-condition-processing.html for details.
This new capability is officially available since OpenEdge 12.0 and was introduced as an unofficial tech-preview in OpenEdge 11.7.4.
To avoid compile errors on OpenEdge releases not supporting the new handling of STOP conditions and to avoid regression issues with customer's applications expecting our legacy handling of STOP conditions the new behavior needs to be turned on in products.i - similar to this here:
&IF 1=0 &THEN
/* Mike Fechner, Consultingwerk Ltd. 02.03.2021
SCL-2461: Support for -catchStop - on OpenEdge 11 */
&ENDIF
&IF NOT PROVERSION BEGINS "11" &THEN
&GLOBAL-DEFINE CATCH-STOP CATCH-STOP
&ENDIF
The new behavior is used, when the CATCH-STOP preprocessor has a non blank value.
Previously when our backend was encountering a STOP condition, the ServiceAdapter and ServiceInterface have been handling those using the traditional DO ON STOP construct and returning an instance of the Consultingwerk.Exceptions.StopConditionException to the frontend. This StopConditionException could not be qualified any further (STOP-AFTER, lock wait timeout, R-Code related issues, DB trigger CRC issue, ...). Especially for the STOP-AFTER condition this was really limiting, as STOP-AFTER is more an application feature used to limit long running AppServer requests rather than any sort of critical system issue.
When the new behavior is used, we will no longer handle STOP conditions on the backend (or elsewhere). The Progress.Lang.Stop derived errors are thrown to the caller and can be catched there. A slight exception here are the Count requests in our web handlers. Those utilize the STOP-AFTER feature to limit long running count requests and return a “magic number” when the result cannot be counted in the desired time.
We have extended the ErrorHelper and LogManager classes to provide functionality to deal with the Progress.Lang.Stop derived instances like with Progress.Lang.Error instances (interestingly, Progress.Lang.Error is just an Interface for errors, whereas Progress.Lang.Stop is a class).
We have also extended the Consultingwerk/Windows/ui-catch.i include file to CATCH Progress.Lang.Stop instances as well and invoke the ErrorHelper to display details from those errors.
We're expecting two consequences for customer applications that enable the improved handling of STOP conditions
- code the explicitly catches Consultingwerk.Exceptions.StopConditionException will not catch anything anymore. The CATCH block for this specific error should be replaced (or an additional CATCH block should be added) with a CATCH block for Progress.Lang.Stop.
- event handlers, that only catch Progress.Lang.Error will no longer catch a STOP condition, as the StopConditionException is implementing this error like all AppError derived instances, but Progress has decided that the Progress.Lang.Stop does not.
As the CATCH-Stop feature was not officially released in OpenEdge 11.7, we do not recommend the usage of the -catchStop 1 Startup Parameter to enable this optional feature on OpenEdge 11.7. While we are aware of any issues, we haven't performed intensive tests with the new feature on OpenEdge 11.7.
We recommend any ABL developer to read the Progress documentation on those described changes about the handling of STOP conditions.
Last modified on 05 Mar 2021 10:03 by Mike Fechner