Jim,

> Exceptions cross library boundaries are always going to be
> trouble.

Ohh, you are even more correct here than you think about it. :-)

> If we build in a function to register a callback
> with a known calling sequence, we can the callback in your
> call to throw the actual exception. The API implementation
> code doesn't care about the mechanisms of the exception, just
> that a responsible adult does whatever is required to make
> sure that it never returns from the exception callback.

Sorry for repeating myself, but I already explained earlier that this
approach is not nice and told about portable alternatives.
Exception handling is not magical thing and compiler needs to know a lot
to throw, pass and catch exception properly.

Any throw code needs to know how to unwind all stack frames for _all_
functions between throw point and catch handler. This is important
point.

Just think, host compiler (the one used to compile application) is going
to unwind stack frames and call destructors of stack objects for the
code potentially built with different compiler.
This is either going to cause crash if stack frame format was
incompatible or no calls of stack unwind handlers.

One of the portable ways to pass exception pseudo-object is to store it
in dynamic thread-specific exception buffer.
Sample Windows implementation of this approach may be found in
BV_Stable3 branch of Firebird tree (see platform.cpp file), it is used
there to implement exception passing across Trace API boundaries.
POSIX implementation is very similar.

Nickolay Samofatov