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

Status
Not open for further replies.
L

Laura Stern

Guest
Yes, what Progress.Lang.LockConflict inherited from was a dilemma for us. We originally made it inherit from Progress.Lang.Stop because it always has been a stop condition, and because there is actually no error message associated with it. Though indeed, there can be a message if you get a lock-wait timeout, but not if you get it via the lock conflict dialog box. We also got a request from elsewhere that it implement Progress.Lang.Error. The deciding factor though was that we thought it might break existing applications if existing Progress.Lang.Error catch blocks caught it, rather than whatever special logic people had put in to handle lock conflict stop conditions. Perhaps that was not valid reasoning? It is very hard to parse these things out. I don't know what you mean by "... there are TWO different Stop errors - for "system" stops vs "supported-abl-feature" stops." Is that the terminology from the documentation? What it means is this. Any stop condition that has an error message, which is basically everything that is raised by the ABL from unexpected circumstances, implements Progress.Lang.Error and inherits from StopError and so would be caught by existing catch blocks for Progress.Lang.Error. Except for LockConflict, already discussed, all of the others happen because of something the application code, or the user, does explicitly. For example, coded STOP, or STOP-AFTER, or the user hitting CTRL-C. There is no error message associated with any of these. Plus, the action for those things will certainly be different than when an unexpected error happens. For example STOP-AFTER is explicitly coded and the app probably wants very specific code to handle it. I think you will see that it makes total sense.

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