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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 27 Nov 2015 13:25:26 +0100
> From: Aurélien Aptel <aurelien.aptel+emacs@gmail.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs development discussions <emacs-devel@gnu.org>
> 
> As tedious as it sounds, checking for errors after every API call is
> the safest way to go.

With the latest emacs-25 branch, we no longer do.  Which is a Good
Thing, IMO.  Writing an Emacs module isn't supposed to be such an
unpleasant exercise.

> We have to remind ourselves we're extending an editor in
> C. Crashing/aborting can make someone loose work.

Who said anything about crashing?  The current code doesn't crash, but
doesn't require error checking in the module code after each call to
an Emacs function.  Please take a look.

Btw, if we are talking about crashing, I think the massive use of
eassert in emacs-module.c is a much more probable cause of losing work
than anything else.  eassert is for things that "should never happen",
not for catching programmer's mistakes.  An assertion that is violated
_really_ crashes Emacs and risks losing valuable work.  Doing that
because some module has a bug is simply unacceptable.

> As ignorant as it will sound, working on the dynamic modules feature
> made me realize how Emacs core might leak memory everytime a call
> signals in the middle a function if you're not careful. I find this
> very error-prone.

You will have to explain that to us, because we do this in Emacs all
the time, and there are no leaks caused by that.