L
Laura Stern
Guest
Re: "Today in my entry-level appserver procedures, I already have to use repetitive code to catch Progress.Lang.Error and subsequently convert to "RETURN ERROR" statement for marshalling over to a .Net openclient. Now that Progress.Lang.Stop has arrived, I will also be forced to catch these new errors in many situations as well" I don't agree with this. Lock conflicts and STOP-AFTER issues should not be bubbling up to the top level .p. They should have been handled where they happened. No? Or do you want to send Lock conflict errors to the client? Wouldn't it be better to handle that on blocks that update the database, and perhaps try again? Those are really the only 2 things we are talking about. Most apps don't use the STOP statement. And on an AppServer, there is not really an issue with UserInterrupt. So it is just lock conflict and STOP-AFTER, and STOP-AFTER definitely needs to be handled in a specific and different way. In theory, I can't argue with you about Lock conflict. i.e,. I really agree that it should just be an error, not even a Stop condition that implements Progress.Lang.Error. It is just an error. But due to history, we were kind of stuck.
Continue reading...
Continue reading...