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

[Philipp Stephani <p.stephani2@gmail.com>]

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

Daniel Colascione <dancol@dancol.org> 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.

[-- Attachment #2: Type: text/html, Size: 2947 bytes --]