>'Thundering Train Programming' is the phrase that came to my mind when trying to characterize a certain way of programming. It is typical for the programmer who is allowed to assume, or assuming, that certain preconditions are always fulfilled according to the functional design and that therefore no checks for those preconditions are required in code. If a precondition is not fulfilled, then the application will simply crash. Such crashes are not the responsibility of the programmer, but of the functional designer.
>
>Why I named it 'Thundering Train Programming'? The train driver pays attention to a lot of things during the trip, but he won't bother about the rails. He assumes the rails exist all along the route. That assumption allows him to speed up the train and pay attention to other things.
>
>Here's a piece of Thundering Train coding:

lparameter tcEmpno
>local ln
>select empname from employees where empno = m.tcEmpno into array laEmpname
>for ln = 1 to alen( laEmpname )
>   do someroutine with laEmpname[ m.ln ]
>next

>It contains no checks at all:
>- It assumes a chartype parameter is indeed passed.
>- The existence of the table is assumed.
>- The existence of the field empname is assumed.
>- It is also assumed that there actually is at least one record found.
>
>Is it bad code? Not as I see it. But the programmer should make clear in the documentation why there are no, or only so little, checks.

Yes, the fourth assumption is extremely dangerous:

If an array does not exist and the SQL SELECT Statement returns one or more records, the command creates an array. An existing array is re-created to accommodate the query results.

Note: If the SQL SELECT statement does not return any records, an existing array remains unchanged and may contain previous results. If an array does not exist, the command does not create one. Consider using the _TALLY System Variable to determine if a SQL SELECT statement returns any records.