[Top][All Lists]

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

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

From: Stefan Monnier
Subject: Re: Dynamic modules: emacs-module.c and signaling errors
Date: Thu, 26 Nov 2015 15:11:25 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

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

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


reply via email to

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