"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 many error
handling patterns a check for GDSCODE is enough to simply rollback a
transaction. The only additional data usually interesting is a full error
text which requires an explicit extra call anyway, be it Paul's proposal or
yours (I hope you don't suggest to call "interprete" code in the constructor
of an error object?). I prefer to get the minimal info automatically and
explicitly ask for extras when I need them. The only benefit I see in your
proposal is that no intermediate storage (either global or thread-based) is
required, but the cost is usage complexity.

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.

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


Dmitry