A few weeks back we were discussing the problems with a language
independent, object based, callback based error reporting system. The
gist of the problem is that stack unwind disciplines are not effectively
standardized on some (or most) platforms, and that cross-language unwind
problems may be unsolvable.

I am convinced that error reporting must be object based for
extensibility. Yes, the 20 word status vector is better than a single
numeric SQLCODE, but its limitation are painfully obvious to just about
everyone. An object (or pseudo-object) based scheme has the
extensibility we need, provided we can solve the mechanics. By
pseudo-object I mean an object defined as simple C structure the first
word of which is a pointer to a function entrypoint vector --
essentially the same structure as a Microsoft C++ or COM object.

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. All errors are reported by calling a method on that
object with to arguments, the address of client-defined pseudo-object
itself and an exception object containing the context of the error. If
an error occurs, the API invokes the error processing method of client
pseudo-object. When that method returns, the API logically returns
normally from client's API call, having destroyed the exception object
and performed any necessary and appropriate cleanup. It is the API
client's responsibility to test the state of his error reporting
pseudo-object to determine whether or not an error was reported. In
other words, individual API functions do not have explicit error
returns, though we would want to define for each call what is returned
in case of an error. For example, a ResultSet.next() method might
return TRUE to indicate that it successfully got the next record. A
FALSE return, however, would mean either end of stream (normal case) or
that an error had been reported.

We would, of course, supply a sample error reporting pseudo-object that
would probably suffice for 90% (or maybe 100%) of usage.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376