On 15 Feb 2005 at 10:55, Jim Starkey wrote:

>>>Here is a scheme that I think is worth discussing. The first
>>>argument of all API functions is the address of a client-defined
>>>error receiving pseudo object.
>>
>> Full mess. Every API user has to implement its own error handling
>>object? Ridiculous! ;-)
>>
>>
>No, Dimitry, that isn't the case. If you had read a little further,
>you would have learned that I also proposed to include a prebuilt
>error handling class that could -- but needn't -- be used.

And what way this prebuilt pseudo-object is going to handle errors?

> Also,
>you've apparently forgotten that the API is not intended for
>application program use -- again, it could, but needn't --

Jim, Jim, Jim, didn't I warned you about using right words? Re-read
your statement. Application Programming Interface (AKA API) that is
not intended for application use?!? It is the best joke I've read
last year.

> but as a
>universal underlaying API to support both the existing DSQL/XSQLDA
>interface and the IscDbc binding of JDBC semantics.

Then, normal exception throwing-catching may work because all this
will happened in one solid module, no?

>Dimitry, you apparently missed school the day they discussed
>functions.

I can tell you for sure that in my scool functions never were
discussed.

>previous paragraph). In my proposal an error object is passed to a
>method on the user supplier error handler object. As long as each
>object is faithful to the respective interface definition, we are free
>to do whatever we wish with the error object(s) and the user with the
>error handler object(s).

Callbacks that receive callbacks as parameters. API which is not
API. Pseudo-object for managing objects. What kind of hallucinogens
do you use to invent all these things? I'd like to have some. ;-)
The first thing that every error handling pseudo-objects have to do
is copy all useful information from received error object into
something internal because livetime of the error object is
unpredictable. What did you say about data copying?
Because of polymorphism error handling pseudo-object can't know how
many data error object may provide. What did you say about freedom?

>Ah, Dimitry, Dimitry, Dimitry! Modern programming has threads and
>threads lead to race conditions.

Oh, really? Let's take a Vulcan as an example of modern
programming. Is it possible to use one connection from many threads
without external serialization there? Two racing queries in one
transaction? No?.. `:-|

> Our friend Nickolay has suggested
>that we stuff error status information in thread data, which would
>work, but is crude, vulgar, and unnecessary.

Right. Error status information may be kept in a serialized object.
Currently connection object is an obvious candidate. No need for
thread vars.

>Which brings us to naming conventions. Since the "get last error" is
>a method in object oriented API,

Object-oriented API? Or pseudo-object-oriented API? They are two
big differences, I'd say.
From our previous discussions I got an impression that we agreed
that Application Programming Interface should be a set of plain C
functions...
--
SY, Dimitry Sibiryakov.