Trapping Error Messages Associated With STOP Condition

Hi Rob, I'll have to think more about the implications of your questions. But the most important thing is, that we can distinguish different STOP causes, especially STOP-AFTER and LOCK-WAIT-TIMEOUT. RUN a missing .p, CRC mismatch etc. are installation problems. And STOP-AFTER and LOCK-WAIT-TIMEOUT are caused by the application behavior, especially STOP-AFTER is more a feature than an issue.

So I'd like to see a StopAfterError inheriting from Progress.Lang.Stop or Progress.Lang.StopError to be able to handle that specifically (very close to an OPEN-QUERY statement causing the STOP-AFTER).

This would a great feature as currently CATCH does nothing with a STOP condition.

1. I think that CATCH should do just that; CATCH all error and stop conditions.

2. I think you can refactor to avoid the DO ON STOP higher in the call stack

3. Engineering needs to make sure that the finally block executes before the final STOP happens. This allows good clean-up.

My 2 Cents

I like it and have wanted this since CATCH was introduced, maybe longer. You might want something (client startup) that would revert to current behavior and not catch STOP conditions. I'm sure you can get this in 11.7.

That’s a very good idea Rob, everyone with some OO background gets bite by this one when dealing with OO ABL :(

Hi all,

I must disagree with the implementation proposal, due to the fact that it changes CATCH semantics.

What I see is two different things when it comes to the STOP:

- The STOP condition

- The ERROR that raised the STOP condition

The STOP condition, for me, *is not an ERROR*, it may be the result of an ERROR. I think you already realized it by proposing two different objects to handle STOP conditions.

Making actual CATCH blocks catch STOP changes CATCH semantics, and I don't like it.

I think you should handle the ERROR that raises the STOP condition (if exists) with current ERROR semantics, that is, with an CATCHable object, that will get caught by existing CATCH blocks, catching base error objects.

BUT the STOP condition should behave as it does, bubbling up, until finding a specific catch block for the STOP, once in a 'secure level'.

The general behavior I want is:

- An STOP condition is raised

- If there is an error associated to the STOP condition, then it will be caught by the corresponding CATCH block, honoring every FINALLY along the way

- The STOP will keep bubbling up until a CATCH STOP is found, honoring every finally block along the way.

Alternative paths:

- If no CATCH STOP is found, current STOP behavior happens, honoring FINALLY blocks

- If no CATCH for the STOP ERROR is found, current *uncatch* behavior happens, honoring FINALLY blocks

So, in the end, you will have to explicitly code for STOP conditions, avoiding getting bitten by the semantic change in CATCH.

Take into account I'm not really versed in STOP condition handling, and that my main goal is to avoid semantic changes.

David,

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.)

I think David is on the mark here in separating the cause from the stop condition itself.  Some of the things which produce the stop condition now are really things that should be trappable.  Give us the ability to trap them and we don't need for it to proceed to stop.  Genuine stop should be reserved for Simon's type three conditions, i.e., something has happened that cannot be sensibly be recovered from.  Then, one wants to capture as much information about what happened in a log and then give up.  Even a missing .p or .cls should be trappable.  Yes, there are some places where if one is missing one doesn't have a very graceful way to recover, but at the least one can give a useful message, log some things, and then fall back to a higher level.  Other places, the missing .p or .cls is just a missing option.

Re the post by cwright on 9/21 @ 14:55:  Yes, if there is a FINALLY block associated with the block that has a CATCH block for STOP, it will execute. This is similar to what happens today with this code - the finally will run:

/* You shouldn't need the ON ERROR part, but currently you do to even compile the FINALLY block */

DO ON ERROR UNDO, LEAVE ON STOP UNDO, LEAVE:

   STOP.

   FINALLY:

       MESSAGE "Finally"

           VIEW-AS ALERT-BOX INFORMATION BUTTONS OK.

   END.

END.

Re Marian Edu's post on 9/22 at 1:20: Re your last paragraph - we did not say this only works for 'stop conditions that have error messages'.  We said "You would be able to code CATCH blocks using either of these new object types." (i.e., P.L.Stop or P.L.StopError.  But only the latter implements Progress.Lang.Error - thus only stop conditions with error messages are the ones trappable by a CATCH block for Progress.Lang.Error or Progress.Lang.SysError.  

You would be able to use a CATCH block explicitly for P.L.Stop to trap STOP raised by the STOP statement, STOP-AFTER or CTRL-C and also for lock wait time-out (which is basically CTRL-C).  

There are other things like GPFs or Out of memory that are not trappable today with DO ON STOP and that will continue to be the case with this new feature.  They will not be trappable.

Re David Abdala's post on 9/22 @ 6:36: Marian already responded to this.  And I agree with her assessment that stop is really some kind of error.  It has always been a bit murky as to why one error condition raises ERROR and another raises STOP.  Sometimes the rationale made sense 30 years ago, but no longer does (e.g., RUN lskdjlfj.p).  

Also, the basic semantics of a CATCH block is that once the CATCH block runs the condition is cleared.  To not do that with STOP conditions seems very confusing.  It is also problematic in that there can be code in the CATCH block that directs the AVM to take some further action, like the NEXT statement.  What would we do if you coded NEXT?  Do we do honor the NEXT or do we bubble up the STOP condition?  It really doesn't make much sense.

I do understand you're wanting to run FINALLY blocks.  We certainly could not do that for cases where we  need to get out of a transaction or DB connection.  But for other blocks -  should we be honoring FINALLY blocks?  I'm not sure that is doable now, but it's an interesting idea.

This seems reasonable. Just add the class name of the error that was thrown to the error messagebox if it wasn't handled. :)

Now let's move on making THROW also consistent, and do away with the inconsistency producing statement BLOCK-LEVEL ON ERROR UNDO, THROW.

Laura, this is from Rob’s original post…

I'm certain I wasn't clear enough.

I think (now) the problem resides in STOP having multiple meanings. I think this is the right opportunity to fix this, and make STOP a unified concept of: execution can't continue due to a general failure condition with AVM, stack is poped up to a safe state, where execution can continue.

So, there are several ERRORs that raised the STOP condition, that now should not do that, they should be just ERRORs following the same rules as any other ERROR. In the other hand you have the STOP condition, that can be set up by a STOP statement, Ctrl+C, a Memory Access Violation, etc. that behaves exactly as STOP does today, ignoring CATCH, and ignoring FINALLY, up to a safe level, this requires explicit coding to be handled, as shouldn't be trapped by "normal CATCH".

There is a "middle ground" approach, where a STOP condition stops execution up to a safe stack level, and at that level it becomes an STOP-ERROR that can be CATCH by normal error handling.

I believe the latter is the way to go, as almost "honors" current behavior, and also "honors" error handling behavior.

1. Is it a good thing that a CATCH for Progress.Lang.Error (etc.) can catch STOP conditions associated with error messages? Is this what you would expect, or would you rather have to code explicitly to catch any STOP condition?

Don't want to code STOP explicitly. Don't care for difference between old ERROR and STOP. Both are the same to me (at a first glance). Of course in special cases, I'd like to differentiate, but in 99% of the cases, there's no difference for me.

2. Do you see an issue in that STOP can possibly get caught before it would have before, which is either never caught or at a DO ON STOP higher up the call stack?

no

3. Is there anything else that OpenEdge Engineering should consider?

no. I'd need that feature very soon. We've tried to introduce structured error handling in the application and still have this ugly "do on stop" statements. Buuuh.

Some of the causes of fatal errors do not have any safe way to continue or to give control back to the 4GL.

And there must be at least one sure-fire way to kill a process when the application will not or actively refuses to stop.

What should be done for those situations?

We're only talking about STOP conditions that have been trappable in the past.  i.e., You can already trap (and therefore clear) the STOP condition with a DO ON STOP statement.  We are not proposing any changes to the kind of fatal errors you are talking about.

Re Marian's post on 9/26 at 14:26: Sorry Marian, but I'm now more confused than before!  i.e., I'm not sure if we are in sync or not.  I don't understand why you said that if we take out the comment about "the ones with error messages" that you like the solution.  

At the risk of repeating myself: Certain STOP conditions intrinsically have error messages associated with them.  The STOP statement is not one of those.  And I agree (with someone above; can't find who) I don't know if anyone actually uses this except for testing or experimenting.  Nevertheless, it exists.  The STOP conditions from STOP-AFTER or CTRL-C also have no error message.  So only STOP conditions with errors can be associated with a P.L.StopError object, which implements P.L.Error.  If there is no error message, it doesn't make sense to map the condition to an interface designed for giving you access to messages and message numbers.  

But we know people would still like to trap the STOP from a STOP-AFTER or a lock wait time-out, etc.  So you can instead catch those by using a CATCH for P.L.Stop. (or some sub-class as a couple of people proposed).  In these cases, there is no message, but you should be able to find out what caused the stop condition via a property of the P.L.Stop object (or by the class type if we use sub-classes).

1. Is it a good thing that a CATCH for Progress.Lang.Error (etc.) can catch STOP conditions associated with error messages? Is this what you would expect, or would you rather have to code explicitly to catch any STOP condition?

>>> A Progress.Lang.Error derived class for STOP with error should be fine. If Progress.Lang.Error is intended to be the base class of all ABL related errors, I would expect Progress.Lang.Error to catch all trappable errors. Having a separate base class for STOP with no message is OK, although I think it is still superfluous (see next answer).

2. Do you see an issue in that STOP can possibly get caught before it would have before, which is either never caught or at a DO ON STOP higher up the call stack?

>>> It might be a good information to know if the error is just a STOP condition, but I really don't see a difference in handling a standard error (or even STOP with message) and STOP condition. Also, the object type is more important than the message itself, so an instance of P.L.Error with blank message is acceptable.

As for the STOP behavior, if I really need to bubble up an error that is already caught, I think implementing a re-THROW (THROW without parameter) that can be included inside the CATCH is fine.

3. Is there anything else that OpenEdge Engineering should consider?

>>> A more consistent THROW.

It might be worth tabulating all of the possible sources of a STOP condition and clearly identifying 2 properties - whether they are reasonably trapable and whether or not there is an associated message.  Then, review the ones without messages and ask yourself if it is appropriate that it have no message.   One of the issues here is the extent to which the condition is likely to occur in normal processing.  STOP-AFTER, for example, is not really a condition where one would expect to bail out, but rather one in which one might like to give information to the user and ask for a course of action.  It seems like it would be easy enough to create a useful message to convey what happened.

Almost always you don't display the message associated with an error verbatim in an application. So to me, knowing the object type is more important than having a message associated with an error. Basically, a P.L.Error derived class for STOP with no message will still work even if the message property is blank.

To be sure, it is my style to program in such a way that the source of the error should be obvious whether there is a nice message or not, but it seems to me that "Query stopped after N seconds", for example, is a trivial addition and adds clarity.

That's true.

If it's my decision, I will go as far as assigning each error (or at least, each family of error) its own super-class to make the structured error handling more robust. But that might be more of a wishful thinking.

wouldn’t that make exception handling a lot more complex?

>

> If it's my decision, I will go as far as assigning each error (or at least, each family of error) its own super-class to make the structured error handling more robust. But that might be more of a wishful thinking.

Not a bit, if one doesn’t care about different types of error the code block could throw away catch-all Progress.Lang.Error is all that is needed.

Laura, if you look at the first post Rob uses exactly that phrase in there a few times… so for me, that sounded like the proposed solution only applies to stop conditions that does not have a message, from what you say this is not the case and everything that we can now trap with `do on error` will be catchable and I’m perfectly fine with that.

On a second thought… how about this slightly changed version?

It is exactly the kind of categorization Marian suggests that I was hoping would fall out of tablulating all the possibilities.  In some cases adding a message to something not now having a message might allow more unitform handling, but one also might identify categories of response which deserve to either be a unique message type within a particular class or which even deserve being a separate class.  E.g., the P.L.TimeOutException could have a property for the number of seconds in the time out.

Will it also be possible to change the ON STOP phrase to allow intercepting the STOP and then throw an error instead, as described in this OpenEdge 11.6 Community Input ?

There's nothing to change other than what has already been said.  If you CATCH the stop condition, the stop condition is cleared.  Then you can do anything you want from there.  If you want to throw an error, be my guest :-)

Thank you for the excellent responses.

One additional question/clarification: this would likely be introduced as an "opt in" feature- the original behavior will stay in place unless you elect to go with the modified behavior. If you opt in, any code that does structured error handling needs to be recompiled (so to be safe, all of your source needs to be recompiled). Is there any issue/concern with a mandatory recompile of your application in something other than a major (OE10/11/12) release? We normally do not require a recompile in "point" releases (11.5, 11.6, 11.7, etc.).

Will you be able to re-throw the current stop condition (or any trappable error) inside the CATCH block just in case you need to bubble the stop condition?

Yes, you will be able to re-throw the P.L.Stop or P.L.StopError object that you caught, which will again raise the STOP condition and will retain all the information in the existing object.

[mention:eec949bfa7364ddbb70465982d500e0f:e9ed411860ed4f2ba0265705b8793d05] , Could you elaborate a little bit more on what you mean by "more consistent THROW" ? What is the inconsistency you are referring to ?

This statement BLOCK-LEVEL ON ERROR UNDO, THROW. There is probably some functional requirements why it is there. However, it makes program behave differently. It's hard to tell sometimes what is going on when the program calls involve mixed programs with the statement specified and others not, why the throw is not being raised or caught. Can it be a standalone statement that can be called anywhere in the code to transfer control over to the structured error handling?

I'm not totally familiar with the BLOCK-LEVEL statement, but is this something that can be parameterized to apply to all programs. 

That was introduced as a convenience so that you would not have to change every block in your code to throw the error to the caller. By default, that doesn't happen so if you want to get an error to be thrown to the caller, you would add that to the top of your procedure and get that behavior.

Now there is a startup parameter named -undothrow that you can specify to change the default error-handling for blocks in ABL code. If you specify -undothrow 2, every single procedure/class that is compiled in that session will be compiled as if you had included the BLOCK-LEVEL statement in them.

Yaaaay.

And if ON STOP is not specified, how will it behave when a stop condition is reached?

Not sure what you're asking.  If you don't use DO ON STOP, and don't have a relevant CATCH block, you will get the old behavior, i.e., STOP is raised and any message is displayed.  

I'm more thinking about the difference between two blocks with CATCH block but one with ON STOP and other has none.

Not sure what you're thinking about, but with the new functionality, if the CATCH block is compatible with the stop condition, there is no difference.  i.e., The catch block takes precedence over any ON STOP phrase, so it doesn't matter if you have it or not.

That is what I'm looking for just trying to get a clarification about the role of ON STOP when a CATCH block is present. I was thinking ON STOP is an override to the CATCH block, and CATCH block will only catch STOP condition when there is no ON STOP.

No.  It will behave the same as for errors.  CATCH blocks override DO ON ERROR phrases.