S
Simon L. Prinsloo
Guest
I distinguish three types of STOP conditions, each with a unique need:: 1. STOP-AFTER - an expected condition that is foreseen by the developer and, by design, is not nearly as severe as any other STOP condition.. 2. STOP raised by conditions that can potentially be recovered from - e.g. a premature menu update give the user an option for which the r-code has not been deployed - no need to kick the user, just tell him "sorry" and life continues. 3. Rather severe STOP conditions, e.g. stack overflows, nesting to deep or loosing the db connection and thereby invalidating some programs in memory. The first type is, for me an "END-ERROR" type of scenario, in that it is expected to happen and must detectable and handled as part of normal program flow. The described behaviour in the proposal will be usable, but the proposal is a bit thin on the ability to distinguish this condition from other STOP conditions. The second type is simply a mislabeled ERROR and the described proposal would finally fix that. The third type is more appropriately handled by the current behaviour of the STOP condition. Note that the "classification" of such a condition may change as the stack unwinds - i.e. when a DB is disconnected, the stack needs to behave as it currently does as long as any program references that database. But once the stack unwound to a level where there is no more references to that database, it should be re-classified to the second type, since we could potentially reconnect the database (a batch job can typically keep trying every x minutes until the db is back and continue its work) or terminate gracefully. As I understand the proposal, it will basically work in the way described for the third type as well. What I am missing and am unsure of, is the following two cases: 1. User hit CTRL-C / CTRL-BREAK - This should probably be handled like STOP-AFTER, in that a human decided that a code block running for some arbitrary time period took too long. The same probably goes for a lock wait timeout raised by the database. 2. The STOP statement. My only use case for the STOP statement is that I sometimes use it during testing or debugging as an quick and easy way to force a "rollback, unwind the stack and terminate" in order to preserve the state of the system from one run to the next, so that I can re-run without the need to change data back. I cannot think of a single case in a production setting in the more than 20 years I am using the ABL where STOP would be an appropriate instruction. Thus, for this STOP statement, I would typically prefer that its behaviour remains unchanged. (Or classify it to behave more like the third type than the second.)
Continue reading...
Continue reading...