Dmitry Yemanov wrote:

>"Jim Starkey" <jas@...> wrote:
>
>
>>This means that some state is returned by the API call as a status,
>>other state must be maintained for arbitrary periods as thread data, and
>>still more state is returned by a GetError function. It is far simpler
>>pass an error object to a method on a client supplied handler object and
>>be done with it. All available context is made available at once.
>>
>>
>
>The question is whether all available context is required.
>

In that case the answer is simple. The error object must have the
ability to capture all known error context.

One client of the this interface is the remote server itself. To avoid
multiple trips, the server must capture and transmit all know error
context. The remote interface, in turn, must capture all context
information provided by server. This means that the API must present
all possible error context under at least one circumstance, so it make
good engineering sense to generalize the mechanism and have full error
context always available to the error handler. Must if use all? No, of
source not. If, in your example, the client cared only about the
SQLCODE, it only needs to ask for the SQLCODE. But since we can't tell
in advance what the client is going to ask so, and transmitting only
minimal context would dictate a round trip back to the server to get the
rest, passing all context through the plumbing is the only reasonable
solution.

>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.

>
>And I'd expect to see more opinions before considering anything "decided".
>Also a few examples from your side would be much appreciated.
>
>
>
>

"Decided" in this context is what I will put in my full proposal. I'm
happy to continue to talk about now and later. I have an existence
proof that a suitable mechanism exists that meets all requirements.
Anything more is icing on the cake.