Le 25-févr.-05, à 13:33, Jim Starkey a écrit :

>> Two possible alternatives which use a combined approach:
>>
>> 3) Every API call returns GDSCODE. GetError returns a reference to the
>> latest error object. The first argument (pointer to the error handler
>> stub)
>> of API is optional.
>> 4) Same as above, but there's no per-call error handlers.
>> SetErrorHandler is
>> offered instead for the global error handling.
>>
>> Both allow async error processing only when it's really important
>> (when a
>> user-defined error handler is provided). On the other hand, they make
>> the
>> entire system more complex. But let's consider them too, just for the
>> sake
>> of wider discussion.
>>
> We only need one error reporting mechanism for the API. We know we
> need
> full context to support remote connections. So we know we need the
> handling object or semantic equivalent. If we have that, and it
> supportes a layered, dumbed-down interface that meets your needs, I
> think everyone should be happy.

Sorry for coming in late in the discussion...

The API Jim proposed is a 'low-level' API, not one intended to be used
straight by high-level application developers. It could of course, and
some will do. But as far I understood the idea the low-level API would
be used by various layers of the project and by interface writers
(odbc/jdbc, .net provider, ibobjects, ibpp, some or most tool vendors
and so on). Those people can afford to use an API with some more strict
requirements than an API intended to application level programmers.

I would really like not to ever have to deal with anything like:

if (some_fb_api(...) == FB_ERROR)
{
someobject o;
GetLastError(o);
...
}

It implies thread storage as was pointed out multiple times here ('it
returns a reference to the latest error object' doesn't stand, except
eventually on a per-thread basis) and I don't feel good at all seeing a
low-level generic interface, on top of which others should be layered,
that itself requires thread storage to even the simpliest thing as
returning error codes and messages.

Jim requirement of using a mandatory additional parameter (be it the
first parameter of each and every call) is appealing, brings coherence,
is powerfull, extensible, and very easy to deal with, except maybe from
within a pure high-level application. But again, the 'market' for the
new API is not the application developer but the plumbing developer.

--
Olivier Mascia


[Non-text portions of this message have been removed]