I was a decision I made in 1982 when I created the API that eventually
became DSRI (DEC Standard Relational Interface) and later, the
GDS/Interbase API.

There are a variety of reasons for the decision. It was anticipated
that most usage of the API would be by code expanded by pre-processor.
Handle variables where generally created by the pre-processor and
consequently inaccessible to the application programmer. In this
context, a bad handle was always the result of a program bug. If
handler variables did not reflect the proper state, a whole class of
bugs would have been undetectable.

A second reason is that most of the pre-processors had options to
generate code to start a transaction if the transaction handle is zero
(just as requests are compiled if the request handle is zero). Without
a convention that a handle variable sans object was reliably zero, this
also would have been impossible.

Finally, mother nature and the software gods abhor uninitialized
variables. Basic software sanitation dictates that handle variables,
like all variables, be initialized before they are used (or, like Java
and the internal memory allocator, set to known states).

On 10/14/2010 2:53 AM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Do anybody know the reason why output parameters (such as transaction handle in
> isc_start_transaction) are required to be NULL on input?
> If you forget to clean the variable before calling isc_start_transaction(), you'll get
> error "invalid transaction handle (expecting explicit transaction start)" which is rather
> confusing because this function is exactly expected to do "explicit transaction start".
>


--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376