Hi Jim,

>I think there's been success in avoiding a general conclusion that EXIT/LOOP are evil commands that are never to be used.

No absolute rule, Agreed,

>The next phase may be to get people to avoid getting cold sweats when they are reading code that has a (some) EXIT/LOOP line(s) in it because all that does is prejudice the reader and so toughen his/her job. For (generally) no good reason.
>
>By the way I can't see ever agreeing that DO CASEs coded specifically to execute every CASE statement (faking a FALSE condition on each to make it happen) is EVER READABLE. IF your definition of readable is fewer indentations then you may think you have a winner, but in fact you don't. I bet that 98% of people debugging someone else's program expects that a DO CASE is testing for (more or less) independent conditions where 1 is EXPECTED TO BE TRUE. What you say is fine is totally contrary to the design intention of DO CASE and in my opinion is genuinely a cop-out from doing things properly. Just because DO CASE *can* be used that way does not make it reasonable to do so. Curious that you feel that you can successfully avoid EXIT/LOOP in your own code (and get worried when you see it in others) yet you happily use a construct exactly against it clear design intention! I'd say yours is one example of the definition of "readability" that could use some reconsideration.

I don't quite get on what specific constructs you're talking about. However if clearly written I don't see a problem with constructs like.

SELECT SentOrders
SCAN
    DO CASE
        CASE NOT THIS.IsInVoiceReady()
            Wait window "The invoice is not ready"

        CASE NOT THIS.IsInvoideApproved() OR NOT THIS.ApproveInvoice()
            wait window "The invoice is not approved"

        CASE NOT THIS.SendInvoice()
            Wait window "The invoice count not been send"

        OTHERWISE
            Wait window "The invoice has been send"
    ENDCASE
ENDSCAN

The example above walks through all send orders. In the first two cases it checks on conditions if an invoice can be check or not, the third tries to send to the invoice. If not succesfull it launches the otherwise.

the algorithm above uses both the strict order of the CASE statement execution to do its job and using functions to return a value. I can't see why this is not readable. In all honesty I think it is far more readable in a case where the actual implementation of the methods are in a long winded SCAN or DO WHILE where you everytime have to figure out what exactly it is supposed to do.

SELECT SentOrders
SCAN
    SELECT Client
    LOCATE FOR Clt_pk = SentOrder 
    IF clt_RequiresCompleteOrderBeforeBilling
        SELECT Orderlines
        LOCATE FOR orl_ordfk = Sentorders.ord_pk AND NOT orl_send 
        IF FOUND()
            ** not the whole order has been send while the client requires so
            Wait window "The invoice is not ready"
            LOOP
        ENDIF
    ENDIF

    IF NOT SentOrder.ord_approved 
       ** Long algorith trying to approve order
       IF NOT lApproved
          wait window "The invoice has not been aproved"
          LOOP
        ENDIF
    ENDIF
 
    ** Long algorithm to send invoice
    IF NOT lSend
        Wait window "The invoice has not been send"
        LOOP
    ENDIF

    Wait window "The invoice has been send"

    .... other stuff
ENDSCAN


Again, whether we talk about DO CASE or LOOP and EXIT, readability and maintainability is in the hands of the programmer. Neither DO CASE or LOOP and EXIT gaurantee properly written code.

Walter,