Dimitry Sibiryakov wrote:

>On 14 Feb 2005 at 16:47, 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. Also, you've
apparently forgotten that the API is not intended for application
program use -- again, it could, but needn't -- but as a universal
underlaying API to support both the existing DSQL/XSQLDA interface and
the IscDbc binding of JDBC semantics. The primary goal, however, is to
eliminate the hideous overhead of copying and converting user data 5
times between engine and client program.

> If you want object-oriented error handling - no problem. But hide
>the object inside of library. Make every API function return one
>single numeric return code which is FB_OK or a handle of an error
>object that may be used in following calls of error-explaining
>finctions like fb_interprete. No "first argument" at all! Full
>extensibility because _you_ have a full control over the error
>object.
>
>

Dimitry, you apparently missed school the day they discussed functions.
A function returns a single value. The value may be a statement object
from compileStatement()l, a boolean value for next(), and an integer
from executeUpdate(). A called function can return both one of these
and an error code. It's possible, of course, to pass variables by
reference, which is what the current OSRI interface does. But I hope
we've all learned from Java that pass by reference is unnecessary in an
object language. While we can't eliminate pass by reference from C++,
we can pretend it isn't there.

I think you've also missed the fundamental concept of object orient
programming, which is polymorphism. Polymorphism means that several
classes expose the same interfaces. In our context, this means that a
user can specify his own error handling and doesn't have to live with
whatever we decide is good for him.

And if you go back and read my message again, you will find that we do
have full control over the error object. Or, even better, we can have
different error objects from different subsystems, each tailored to the
specific need (this is an example of polymorphism discussed in the
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).

> Or even better: let API functions return GDSCODE for backward
>compatibility, but introduce another function (say,
>fb_get_last_error()) which, being called immediatelly after failed
>call, returns the handle of the error object.
>
>

Ah, Dimitry, Dimitry, Dimitry! Modern programming has threads and
threads lead to race conditions. Our friend Nickolay has suggested that
we stuff error status information in thread data, which would work, but
is crude, vulgar, and unnecessary. But, if you really want a
fb_get_last_error(), all you need to do is implement it as part of your
error handler class. You wouldn't need to, of course, because any
rational implementation of an error handler would capture the state of
the error condition, but if you wanted to, you could:

DmitiryErrorHandler* DmitiryErrorHandler::fb_get_last_error()
{
return this;
}

Which brings us to naming conventions. Since the "get last error" is a
method in object oriented API, it is implicitly qualified by the class
name, and doesn't need the "fb" prefix. Also, I think, maybe
incorrectly, that method names will follow modern naming conventions.
You probably would be happier calling your pointless method getLastError().

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376