Add an option not to throw ContextNotEnded

[dereckson]

Use case: add e4c to an library/extension/plugin with an entry point and an optional exit point.

I've tested this:

• init code: e4c_context_begin(E4C_TRUE);
• exit code: e4c_context_end();

If the main software exits property unloading the module, all is fine.

But if it exists without unloading it, e4c_context_end throws a ContextNotEnded exception.

A mechanism to end the context implicitely or ignore the issue would be interesting.

[guillermocalvo]

exceptions4c provides a macro e4c_reusing_context which allows for exception handling inside library functions. This macro reuses an existing exception context, if available when the library function was called. If there is no current exception context, then begins a new one and automatically ends it when finished.

This is an example of the intended usage:

int library_public_function(void * pointer, int number){

    // We don't know where this function is going to be called from, so:
    //   - We cannot use "try", "throw", etc. right here, because the
    //     exception context COULD be uninitialized at this very moment.
    //   - We cannot call "e4c_context_begin" either, because the
    //     exception context COULD be already initialized.
    // If we have to make use of the exception handling system, we need
    // to "reuse" the existing exception context or "use" a new one.

    volatile int status = STATUS_OK;

    e4c_reusing_context(status, STATUS_ERROR){

        // Now we can safely use "try", "throw", etc.
        if(pointer == NULL){
            throw(NullPointerException);
        }

        library_private_function(pointer, number);
    }

    return(status);
}

I plan to enhance the documentation at the library home page but so far I haven't had the time to do it. In the meantime, you might want to take a look at the source code.

I hope this works for you; please let me know your thoughts about it.

[dereckson]

Yes, this works well, and indeed, the e4c.h documentation is well written and clear.

I would also suggest to include a sample with the signal handling (with the warning we catch host signals too, even if it's logic, it's well to warn about it), maybe using the normal e4c map instead of a custom one:

        const e4c_signal_mapping *old_mappings = e4c_context_get_signal_mappings();
        e4c_context_set_signal_mappings(e4c_default_signal_mappings);
        [...]
        e4c_context_set_signal_mappings(old_mappings);

Or are there signals we absolutely need to let the host intercept?