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

[Daniel Colascione]

On 11/24/2015 11:58 PM, Paul Eggert wrote:
> Daniel Colascione wrote:
>> What's your alternative?
> 
> I don't have one right now. But surely a better API can be devised.
> 
> I agree that checking errors in return values is reasonable for things
> like 'open'. But memory allocation is so basic.

You could argue that file descriptors are basic. They're just handles to
bits of kernel memory, right?

Memory is a resource like anything else, and like all resources, can be
exhausted. (Overcommit is no answer: you can't overcommit address
space.) We have to do _something_ on memory exhaustion, and the only
reasonable choices are communicating the failure up the call stack and
aborting.

Aborting is brittle, so I'd rather not do it. In the Emacs core, we can
activate the low-memory code and let users save work, but if we abort
because a module asks us to allocate, we'll lose data.

> Plus, the method for
> checking errors in the current API is awkward and confusing. It'd be a
> real turnoff to have to use it after each little step in one's program.

Well, there's the Xlib method, where calls just silently fail until you
bother checking for error. I think that's even more cumbersome, since it
makes isolating the source of an error difficult unless your program
runs in synchronous mode.

Lots of extension APIs require error checks. Python's in particular
comes to mind. Using these APIs doesn't feel particularly onerous.

That said, I agree that the specific API for error checking is
cumbersome. The function name is long, and comparing the value it
returns to a specific sentinel feels awkward. IMHO, we could simplify it
to if(env->error_p(env)) { return NULL; } (The name "error" here isn't
strictly accurate, but I think it's close enough, and it's short.

signature.asc
Description: OpenPGP digital signature