Feature -catchstop 1 is a tech preview in 11.7.x ...

you know, you can change setting for the loc-wait timeout.

the optimum setting is application and need dependent. don't be afraid to change its value to something that suits you.

Gus, I think you may have answered the wrong question.  

> On Mar 18, 2019, at 2:57 PM, Laura Stern wrote:

>

> Gus, I think you may have answered the wrong question.

>

>

>

wouldn't be the first time !

Ten seconds seems fine to me.  (It seems to me that lock-waits should have *always* been this short ... is there any point in having an ABL client session sit around for 30 mins? )

The only thing which is unfortunate about the STOP after ten seconds is not having any of the related details.  

I suppose I need to change scope of the ON STOP blocks so there isn't so much uncertainty about why the STOP had occurred.  Ideally we should be using the catchstop to eliminate the uncertainty altogether. But I'm not sure whether we need that feature bad enough to ignore Progress' warnings about the fact that this is a "tech preview".

I wouldn't worry about using -catchStop 1.  We believe it works correctly.  And when we have found a bug, we've fixed it in 12.0 and in the current 11.7 service pack, and will continue to do that.  For some reason, I thought that we had removed the "tech preview" status in one of the 11.7 service packs.  But I need to check on that.  The documentation cannot be updated, so that will continue to say it is a tech preview one way or the other.

Though FYI: There is a bug (OCTA-11633) I am fixing right now, which really was there for a long time, but now shows up in more places due to -catchStop 1.  The fix will go into 12.1, 11.7.5 and an 11.7.4 hot fix.  It affects error messages that come from default widget validation, like Date field validation.  The errors were not being displayed if you were using CATCH blocks.

Thanks for the information Laura.  It is very helpful and it eases my concerns about the bit where this is called a "tech-preview".

STOP's happen very rarely within the custom ABL code that we are hosting in PASOE.  

When & where the STOP's do happen, I'd love to wrap a TRY/CATCH/THROW around them.  That way we could send more of the underlying details back to a .Net openclient.  Our openclients would be able to respond totally different if the STOP occurred as a result of a simple lock-wait timeout (rather than occurring because of a critical runtime compiler issue, database disconnection, etc... some of which are probably not even trappable).  

(For example a STOP condition that was the result of a lock-wait timeout could have a .Net-based retry loop around it.  But other types of STOP's may never clear up, no matter how many times you retry.)

Yes, for lock-wait timeout issues, using -catchStop 1 would be much better :-)  And that bug I mentioned would not happen in PASOE.

I would like to reiterate that the STOP condition handling using stop objects is fully supported within OpenEdge.  STOP condition handling using stop objects was a "Technology Preview" feature in OpenEdge release 11.7.0. It is now a fully implemented and supported feature for OpenEdge ABL as of 11.7.3. However, you must still opt-in to the new behavior by using -catchStop 1. (The new behavior is the default in 12.0).

Background

In 11.7.0 five new built-in objects were introduced:

• Progress.Lang.StopError

• Progress.Lang.Stop

• Progress.Lang.StopAfter

• Progress.Lang.UserInterrupt

• Progress.Lang.LockConflict

In 11.7.3 functionality was introduced to allow FINALLY blocks to execute as part of stop processing.

That is sounds like a very strong endorsement, and I will be happy to use this.  We need it to catch lock-wait-timeouts in 11.7.3 and beyond.  Thanks!

I am a bit surprised by the class hierarchy of some of these classes (eg. Progress.Lang.LockConflict, and Progress.Lang.Stop). ...

Some of them don't seem to derive from Progress.Lang.ProError, nor implement the interface Progess.Lang.Error (which is so common that it is even implemented by exceptions from the CLR bridge). I tried catching it as Progress.Lang.Error and it didn't work.  But I can catch LockConflict explicitly.

Also it took a while for me to pick up on it but I see that there are TWO different Stop errors - for "system" stops vs "supported-abl-feature" stops.

(ie. Progress.Lang.StopError and Progress.Lang.Stop respectively).  That is going to be a bit confusing.  Also, the one for "supported-abl-feature" is the one that I would have thought should implement the generic Progress.Lang.Error.  (So that they would be caught by some of our existing/generic CATCH statements).

I will play around a bit and hopefully it will eventually make more sense.  Here is the link to the CATCH documentation with the description of the two different STOP errors:

documentation.progress.com/.../index.html

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.

Thanks for explaining the reasoning behind the two variations of STOP (Progress.Lang.Stop and Progress.Lang.StopError).  Below is a screenshot from the docs

I suppose I can see the risk in allowing the existing catch blocks to start catching new types of problems like lock-conflicts, stop-after, etc.  But I'd say an ABL developer should expect the change in behavior because (1) they were the ones who had determined to catch the *generic* Progress.Lang.Error in the first place... be careful what you ask for because you might get it ... , and (2) it is at their own discretion to switch over to using "-catchStop 1" (at least for as long as they are on OE 11.7.x)

The model I use in my head for S.E.H. error-handling puts "Progress.Lang.Error" in a special place.  I think of it as being sufficiently generic that it catches almost anything that can go wrong, (short of unplugging the computer, or kill -9, or running out of RAM).  It seems like that should be especially true for problems which are self-inflicted because of the design of the logic or the configuration of timeouts (stop-after timeouts, lock-conflict timeouts, etc).  

Going forward, I will have to remember that "Progress.Lang.Error" isn't sufficiently generic to catch timeouts (stop-after or lock-conflict).  Maybe OE will need to come up with a new "catch-all" interface that combines the "Progress.Lang.Error" with "Progress.Lang.Stop".  

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, making the code in the entry-level procedures even more repetitive.  Perhaps I will have to go back to using compile-time include, eg. {Includes/RepetitiveCatchBlock.i}.  As a side note, the STOP condition does get marshalled to the .Net openclient already (for free) but I don't believe that the .Net side can distinguish a LockConflict from another type of STOP. 

See screenshot below.  This is what we see when a STOP is passed (for free) to the openclient.  Notice that it is very generic and there is nothing about it that can be used to distinguish that this one was caused because of a 10 second lock-wait timeout.

... so if we want a short ten-second "lock-wait", or if we need any "stop-after" functionality, it means we have to always introduce additional CATCH blocks.  The additional CATCH blocks are needed for Progress.Lang.Stop in addition to the ones we already have for Progress.Lang.Error.  Both CATCH blocks will need to translate the underlying details into a "RETURN ERROR" statement with sufficient explanation of the problem.  Once it is translated, it can pass along to the .Net side.

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.  

Writing custom catch blocks too early (high in the callstack) is labor-intensive.

There is usually no need to do that, nor to interact with particular exception-types that had caused a failure.  As far as the user is concerned, either things worked or they didn't.  If not, then show the user a message that contains a reasonable string representation of the error message.   Showing a error message can happen in a generic way, as long as there is an error and a related message.

In many cases, the developer may not initially be *aware* of every possible type of exception that could cause failures.  (Eg. your ABL code might be running in a new and unfamiliar container, like PASOE, or the code may be interacting with unfamiliar services that were written by a third-party).  So initially you treat all exceptions the same and, over time, if you want to handle some of them differently you might do that (with retry logic, or customized messages, etc).  Some types of exceptions (concurrency timeouts for example) happen so infrequently that we might never choose to clutter the code with any specific references to them at all - if we can avoid it.  So long as the user gets a somewhat meaningful failure message and understands how to take a follow-up action, then things are fine.

In summary ... our exceptions will be treated in the most generic way possible, unless there is a really, really good reason to micro-manage one of the exception-types.  We don't initially start by trying to micro-manage every possible exception-type if we can avoid it.