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

[Stefan Monnier]

>> 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.

>> 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.

>> The current "funcall" should be renamed to "safe_funcall", and a new
>> "funcall" should be provided which does not catch signals.
> I still think we should be pragmatic about that, not radical.

That's exactly what I am.  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.

> 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.

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.


        Stefan