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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Thu, 26 Nov 2015 15:11:25 -0500
> 
> >> Because this loses the connection between the signal and its origin.
> > Not really, it doesn't.  You get the same Lisp error you'd get in
> > Emacs proper.
> 
> That's only the signal, not its origin.  Its origin is lost.

Not sure what you mean by that.  The origin is clearly stated in the
error message.

> >> Because it imposes a cost which we may not want to pay.
> > What cost is that?
> 
> Catch and then rethrow.  Which is pure cost with no benefit, if you ask me.

A cost very close to zero.  Let's keep the proper perspective.

> The straightforward code doesn't
> catch&rethrow, so rather than let people do funcall_without_catch by
> testing if the not_so_plain_funcall has caught a signal and then rethrow
> it, it makes a boat load more sense to do it the other way around and
> let those who need the signals to be caught to request explicitly the
> not_so_plain_funcall.

No one needs to do anything, the code is already written, and module
authors don't even need to know it exists, or what exactly does it do.

> > If the cake can be had and eaten, too, why not?
> 
> I'm fine with having both funcalls available.  I just want to have the
> "raw" funcall advertized at least as much as the other, and
> the other one built on top rather than the other way around.

Feel free to add it, then.

> I actually find it difficult to believe I have to argue this point.
> It's so blindingly obvious from a simple engineering perspective, not to
> mention the decades of experience with using a "raw non-catching
> funcall" from Emacs's C code.

It's not obvious to me, sorry.  The costs of the current code are
minimal, and the advantages to have the "raw" functionality in
addition to what we have aren't clear-cut.