Providing userdata in abortHandlers

[Ralf Ramsauer]

Hi,

first: Thanks for the great project and its very convenient and straight-forward API.

I am using libzdb inside a C++ project. This project uses multiple SQL connections to different servers. If one of those pools reports any errors, I need to be able to differentiate between different connections.

In the current implementation of zdb, i would have to use different abortHandler functions for different connection pools. This is not possible, as i might have an arbitrary number of pools.

So it'd be great if the

void ConnectionPool_setAbortHandler(T P, void(*abortHandler)(const char *error));

would turn to:

void ConnectionPool_setAbortHandler(T P, void(*abortHandler)(const char *error, void *userdata), void *userdata);

I think you get the idea :-)

What do you think about it? Thank you for comments.

Cheers Ralf

[Tildeslash]

It is true that the _setAbortHandler can be improved so. However the AbortHandler is meant to be a last resort and libzdb's "exceptions" should really be used to catch errors from the library. Because longjmp is used, relying on the abortHandler can lead to resource leakage. Matthieu Verbert has created a C++ bindings library for libzdb which might be more convenient to use from C++, https://github.com/mverbert/libzdbmm. If there is a problem associating Connections to its parent pool, a new Connection_getPool() function can be added if that helps?

[Ralf Ramsauer]

Thanks for the fast reply. I think I misunderstood the meaning of the abortHandler. Now that I see the libzdbmm implementation I think i got it how to properly catch those nifty "C++-style exceptions in C".

Anyways, but still I think that providing userdata might be very useful. Think about that: Somewhere in your code you forgot to catch an exception. The default abort handler would ungracefully exit the program, if you define your own abort handler it would not be able to figure out which pool threw the exception which also forbids a graceful shutdown in case that you have more than one pool.

Cheers Ralf

[Tildeslash]

Although the Abort Handler might benefit from this change in some way, in practice the Abort Handler is a last resort and only called on Out-Of-Memory errors or on uncatched exceptions.

[Tildeslash]

Removing version: 3.0 (automated comment)