emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philipp Stephani
Subject: Re: Dynamic modules: emacs-module.c and signaling errors
Date: Wed, 25 Nov 2015 18:26:31 +0000



Daniel Colascione <address@hidden> schrieb am Mi., 25. Nov. 2015 um 10:11 Uhr:
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.


I'm not a fan of this idea. It is unlike all other C APIs I'm aware of and I think the behavior would be quite surprising to the module author. After all, it causes code to silently do nothing if doing something was requested.

I see a couple of alternatives:
- If an unhandled error is detected, crash unconditionally, even if checking is disabled. This would be consistent with the behavior of structured exceptions in popular programming languages, and would make bugs very obvious.
- Ignore unhandled errors, proceed as if no error happened. This would be consistent with popular C APIs such a the C standard library itself and POSIX.
- The current approach: crash if checking is enabled, ignore otherwise.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]