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?
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).
>>> 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).
>>> 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.
>>> 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.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
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.
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.
Progress.Lang.StopError (aka P.L.StopError)
This object would inherit from Progress.Lang.Exception.
This would be associated with any STOP condition (anything really that doesn’t need failsafe approach), it might or not have any error messages.
This object would inherit from P.L.StopError, fired when a timeout occurs on STOP-AFTER.
Progress.Lang.ClassNotFoundException (couldn’t find a more appropriate name, sic)
This object would inherit from P.L.StopError, fired when procedure not found on RUN or DYNAMIC-NEW.
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 ?
Simon L Prinsloo