Re: Dynamic modules: emacs-module.c and signaling errors

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

On 11/25/2015 12:50 AM, Daniel Colascione wrote:
> On 11/25/2015 12:24 AM, Paul Eggert wrote:
>> Daniel Colascione wrote:
>>> You could argue that file descriptors are basic. They're just handles to
>>> bits of kernel memory, right?
>>
>> I'm not making that argument. I am arguing that memory allocation is
>> basic, though. It really is. It happens *all the time* in the C code
>> inside Emacs, and it's almost surely going to happen all the time in
>> module code as well. It should be easy, not a pain.
> 
> Modules in C already have to handle checking for failures of their
> internal allocations. What makes checking for failures of Emacs-side
> allocations so much worse?
> 
> There are ways of making working with Lisp easier while preserving
> robustness.

Another option for making the Emacs API more ergonomic might be to
define most functions to do nothing if we have non-local control flow
pending, even on otherwise-invalid inputs. (That's opposed to making
emacs_env calls with pending non-local control into a programming
error.) That way, you'd be able to write something like this...

int64_t vplus1 = env->extract_integer(env, env->eval_fmt(env, "(1+ blah
%v)", v));
if (env->error_p()) {
  return NULL;
}

... and preserve whatever went wrong inside eval_fmt, not abort or raise
some generic "invalid call to extract_integer" error.

I'm not sure that this scheme is a good idea, but it does make for
shorter code while still allowing us to propagate errors from any spot
inside Emacs.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]