Wietse Venema writes:
(...) A few alternatives:
- When a request fails, return a distinct error code such as MDB_PANIC, and allow the application to look up the text for the error.
For internal errors, yes. It'll take a fair amount of work to get there. And I don't expect ldmb to become enthusiastic at catching user errors, so those may cause crashes or other misbehavior anyway. After all you can disable asserts with NDEBUG, but then you may get e.g. NULL dereferences instead.
- Invoke an application call-back function with the error code and problem description text. If the error code is MDB_PANIC then the application knows that it needs to make final arrangements.
Sounds good to me for now, since it doesn't mean walking all over the code. mdb.c can just #define its own assert(). No error code, the context is just "we're about to abort" and I don't know of other planned callbacks which the code would help.
/** User-settable callback for assert(), called before abort() * instead of printing the message. * * assert(some user errors) might be unaffected. This hack * should become obsolete as lmdb's error handling matures. * @param[in] msg The assertion message, not including newline. * @parem[in] info Currently NULL. Might change in the future. */ extern void (*mdb_assert_cb)(char *msg, void *info);
(Or maybe call it -before- printing the message, you can abort or longjmp yourself if you don't want the message.)
The second option preserves 100% backwards compatibility. The first option may cause functions to return a result that they didn't return previously.
This is about situations where mdb didn't return at all, so compatibility with old behavior will rarely be a problem with new error codes.