Both duk_hthread and duk_context typedefs resolve to struct duk_hthread
internally. In external API duk_context resolves to struct duk_hthread
which is intentionally left undefined as the struct itself is not
dereferenced. Change internal code to use duk_hthread exclusively which
removes unnecessary and awkward thr <-> ctx casts from internals.
The basic guidelines are:
* Public API uses duk_context in prototype declarations. The intent is to
hide the internal type, and there's already a wide dependency on the
type name.
* All internal code, both declarations and definitions, use duk_hthread
exclusively. This is done even for API functions, i.e. an API function
declared as "void duk_foo(duk_context *ctx);" is then defined as
"void duk_foo(duk_hthread *thr);".
Instead of having a separate panic concept which previously differed from
fatal error handling in that there was no context attached to the error,
use fatal errors also for call sites which previously used the panic handler.
Because these call sites are context-free (DUK_ASSERT() failures) simply call
the Duktape-wide default fatal error handler instead of the user fatal error
handler. For heap creation errors (self test failures) the udata is available;
for assertion it isn't and NULL is used instead.
Add a config option to replace the Duktape-wide fatal error handler; the
default one just segfaults on purpose, to avoid creating postability issues
by depending on e.g. abort().
Remove the error code from the fatal error function signature (it's mostly
pointless) and change the "ctx" argument to "udata" (heap userdata) which is
less confusing than an arbitrary context related to the heap (especially
because it's unsafe to actually use the "ctx" to e.g. call into the Duktape
API).
The fatal error signature change also affects the duk_fatal() API call, which
loses the error code argument.
* Define duk_internal_exception, a plain exception class, wihch is used as
the value thrown for Duktape internal long control transfers. The value
intentionally does not inherit from std::exception so that it'd be as
unlikely as possible that user code would catch the internal exception
type; only a "catch (...)" would catch it.
* Replace DUK_SETJMP() if clauses with "try", and SETJMP() error handling
blocks with "catch (duk_internal_exception &exc)" blocks.
* Also add clauses for "catch (std::exception &exc)" and "catch (...)" to
catch C++ exceptions thrown by user code which are propagated to Duktape
try-catch blocks. Such exceptions are converted to API errors. For now
it's not supported for user code to propagate a C++ exception "through"
Duktape, as that would require some semantics changes to (native) protected
calls. Catching and converting such exceptions to API errors makes the
user code error apparent and easier to fix.
Sami Vaarala