[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic modules: emacs-module.c and signaling errors
From: |
Eli Zaretskii |
Subject: |
Re: Dynamic modules: emacs-module.c and signaling errors |
Date: |
Thu, 26 Nov 2015 22:19:18 +0200 |
> 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.
- Re: Dynamic modules: emacs-module.c and signaling errors, (continued)
- Re: Dynamic modules: emacs-module.c and signaling errors, Paul Eggert, 2015/11/25
- Re: Dynamic modules: emacs-module.c and signaling errors, Eli Zaretskii, 2015/11/25
- Re: Dynamic modules: emacs-module.c and signaling errors, Paul Eggert, 2015/11/25
- Re: Dynamic modules: emacs-module.c and signaling errors, Stefan Monnier, 2015/11/25
- Re: Dynamic modules: emacs-module.c and signaling errors, Eli Zaretskii, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Stefan Monnier, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Eli Zaretskii, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Stefan Monnier, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Eli Zaretskii, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Stefan Monnier, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors,
Eli Zaretskii <=
- Re: Dynamic modules: emacs-module.c and signaling errors, Paul Eggert, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Philipp Stephani, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Philipp Stephani, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Stefan Monnier, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Daniel Colascione, 2015/11/26
- Re: Dynamic modules: emacs-module.c and signaling errors, Stefan Monnier, 2015/11/27
- Re: Dynamic modules: emacs-module.c and signaling errors, Eli Zaretskii, 2015/11/27
- Re: Dynamic modules: emacs-module.c and signaling errors, Eli Zaretskii, 2015/11/27
- Re: Dynamic modules: emacs-module.c and signaling errors, Aurélien Aptel, 2015/11/27
- Re: Dynamic modules: emacs-module.c and signaling errors, Eli Zaretskii, 2015/11/27