[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Unsafe error behavior in legacy ABL loops

Status
Not open for further replies.
D

dbeavon

Guest
I agree in principal to your ON ERROR recommendations. Is this a standard programming practice whenever you are updating the database in a loop? Is there some unstated pattern that says *every* ABL loop involved in a transaction must specify "ON ERROR" to avoid bugs? Why is this pattern overlooked in so much of our legacy 4GL code? The legacy code I'm referring to was not written by novices, but by experienced programmers/consultants who specialized in delivering entire ERP's based on Progress 4GL . It is probably just a matter of semantics but the ABL language and runtime environment *is* allowing transactions to be partially committed. I would agree with you that the underlying OE database itself may not be responsible for losing any data. But the language and runtime environment certainly is ensuring that the loss of data is the "default behavior" whenever an error condition is raised in a loop. The problem with FOR EACH loops is that a developer may initially write them to do one simple thing. That thing could be so simple that it can't possibly raise an ERROR, like assign an established memory variable to a list of database records. But after some time another developer may need to come along and add a new line of code, and another, and another. Soon there is a lot of code in the loop, some of which has the potential to raise an ERROR condition (whether that scenario has been explicitly tested for or not is another matter). The final result of all this is very bad. We suddenly start experiencing unexpected data loss in certain unusual scenarios - because individual database records are quietly UNDO'ing themselves. If there are other ideas for fixing our legacy code to avoid data loss, I would appreciate hearing about them. Unfortunately I'm guessing there won't be a silver bullet that fixes the entire ERP at once. Structured error handling (SEH) would certainly come in handy here but I'd like to avoid making changes that would be unfamiliar to an old-school ABL programmers, who aren't comfortable with either OO or SEH.

Continue reading...
 
Status
Not open for further replies.
Top