Trapping Error Messages Associated With STOP Condition - Forum - OpenEdge Development - Progress Community

Trapping Error Messages Associated With STOP Condition

 Forum

Trapping Error Messages Associated With STOP Condition

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

    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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

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

    I’m definitively for identifying errors by type whenever possible but introducing that in AVM generated errors would probably too much of a stretch so we can live with SysError when it comes of errors generated by AVM.

    What I would love to see implemented is an option to add ’throws’ information of method/function/procedure definition so one knows what kind of errors to expect (extend the IDE to support that with some code completion will be nice as well).

     
    Marian Edu

    Acorn IT 
    +40 740 036 212

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

    As Thomas said there are probably only a hand full of ’stop conditions’ that can occur - and we can catch - so I would say different subtypes of P.L.S errors would be nice and don’t bother with the extra property.

      
    Marian Edu

    Acorn IT 
    +40 740 036 212

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

    Progress.Lang.Exception
    New root interface, Progress.Lang.Error will inherit from it.

    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.

    Progress.Lang.TimeOutException

    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.


    No idea how easy this could be implemented, if possible, but it won’t change anything on existing code… aka, no stop conditions will be unintentionally catch by P.L.SysError or P.L.Error blocks. If we need to catch everything it’s just a matter of changing P.L.Error to P.L.Exception.


    Marian Edu

    Acorn IT 
    +40 740 036 212

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

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • 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

    www.vidisolve.com