Re: Pro*C/C++ and the goto operator

Alex Vinokur wrote:
>
> > If you follow Oracle's method of using Pro-C your
> > code will be highly portable and maintainable.
> >
> > There is an alternative to the goto. You could write something to the
> > effect of:
> >
> > EXEC SQL WHENEVER NOT FOUND DO myfunc();
> >
> > If you do it that way, if a fetch causes a 1403 then myfunc() will be
> > called, but that may not give you the desired result.
>
> Why may result be undesirable?
>

If you do not return a value from the function that you call and if you do not trap that value, the expecution path may continue as if there were no error. At a very minimum you would need to do something like:

EXEC SQL WHENEVER NOT FOUND DO val = myfunc();

And then immeiately after the EXEC SQL that contains the open/fetch/close, etc. etc. you would need to check the value of 'val' and determine what to do based on that value.

> (We don't need goto-operator in C/C++.
> Do we have to use this operator in Pro*C/C++?)
>

The convention wisdom to not use goto is one of the lamest things that has ever crept into the lore of programming. The use of "GOTO" is not evil, only its mis-use. In the normal course of programming there are occasions where a judicious use of "goto" will actually make the program better. I've seen horrific programs which had line after line of unnecesssary code that was written just so a goto could be avoided. My strongest suggestion to anyone who reads this is to completely forget that you ever heard anything negative about using "goto". And by this I am not saying that anyone should liberally sprinkle "goto" throughout their code, but it does have a proper function and if it is not abused it can actually make code better.

Now that I have gotten that off of my chest, let's get back to PRO-C. Oracle had a very good reason for including the

EXEC SQL WHENEVER SQLERROR GOTO mylabel;

functionality. The basic intention is that if an erorr does not occur, execution will continue with the next statement after whatever SQL statement is executed. However, if an error occurs the exeucution will branch around the this code to an error handler. For example, here is a simple function which uses this logic:

static int Ora_Commit(void)
{

    EXEC SQL WHENEVER SQLERROR GOTO SQLERR;     EXEC SQL COMMIT WORK;
    return(0);

SQLERR:
    return(1);
}

I think this is extremely clean to anyone who understand C and it solves the problem succiently and portably.

Of course, all of this assumes that programs are written in a structured manner. Most programmers are not very good at writeing structured programs (a large percentage have a bad habit of cramming every possible into main()). If you write good structured programs, the Oracle way of writing Pro-C will work for you every time. I know this because whenever I write a Pro-C program I use the Oracle-endorsed methods and I have yet to discover a single instance where this has resulted in a program that doesn't function properly. Received on Tue Oct 05 1999 - 07:30:22 CDT