OpenEuphoria

goto considered essential, revisited

• Posted by Tom Dailey <thomasdailey at comcast.net> Jan 22, 2006
• 456 views

This conversation seems to be wandering away from my original
point. I am NOT advocating the addition of the goto statement
to Euphoria. In my 38 years of experience as a systems
programmer, I have seen much confusion caused by the unrestricted
use of goto statements (or, before 1977, branch instructions), 
and I have spent literally thousands of hours untangling and 
rewriting the resulting spaghetti code.  What I AM advocating is 
the addition of a very constrained control flow construct that 
will allow graceful coding of abnormal procedure returns, AND 
NOTHING ELSE. Please read the following code carefully.

    function    copyfile
    (
        sequence    input_file_name
        sequence    output_file_name
    )
        integer     input_file_nr
        integer     output_file_nr
        object      line
   
        input_file_nr = open ( input_file_name, "r" )
        exception cant_open_input_file if input_file_nr = -1
        output_file_nr = open ( output_file_name, "w" )
        exception cant_open_output_file if output_file_nr = -1
        while 1 do
            line = gets ( input_file_nr )
            exit if atom ( line )
            puts ( output_file_nr, line )
        end while
        close ( input_file_nr )
        close ( output_file_nr )
        return outcome__success
        --
        -- Exception handlers must follow the main body of 
        -- the function or procedure. They are ONLY executed
        -- via an exception statement in the main body.
        --
        when cant_open_input_file do
            return outcome__cant_open_input_file
        when cant_open_output_file do
            close ( input_file_nr )
            return  outcome__cant_open_output_file
   
    end procedure -- copyfile

In considering this code, remember that, in a real world case,
a function might detect 5 or 6 abnormal conditions, and, for
each one, need to perform several cleanup actions before returing
an appropriate error code. The proposed exception handling
construct is merely a disciplined mechanism for removing such
actions from the main (non-error) logic, with the intent of 
making that logic easier to read.

Tom