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

[Stefan Monnier]

>> So you're saying that if I call a command which internally calls
>> a C module function which turn does "env->funcall" on some Elisp code
>> which then signals an error, I'll be throw into the *Backtrace* buffer
>> (after setting debug-on-error and not debug-on-signal) right at the
>> point where the error is really signaled (i.e. before returning to the
>> module's C code), and not later on when it is rethrown by the module
>> code?

> Yes:

>   emacs -Q
>   M-x load-file RET modules/mod-test/mod-test.dll
>   M-: (mod-test-string-a-to-b (string-match "a" nil) "b") RET
>    =>
>      Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>        string-match("a" nil)
>        (mod-test-string-a-to-b (string-match "a" nil) "b")
>        eval((mod-test-string-a-to-b (string-match "a" nil) "b") nil)
>        elisp--eval-last-sexp(nil)
>        eval-last-sexp(nil)
>        funcall-interactively(eval-last-sexp nil)
>        call-interactively(eval-last-sexp nil nil)
>        command-execute(eval-last-sexp)

Hmm... that's not the case I'm talking about: here the string-match is
called before even entering the module's code, so the module code is not
involved at all.

>> >> The core provides naturally a plain raw non-catching funcall, but with
>> >> the current design a module author who wants this behavior can't have it
>> > Why would a module author want a non-catching funcall?
>> Why not?
> Sorry, "why not" is not an answer.

Given then 271-vs-15 rather of non-catching funcalls vs catching
funcalls in Emacs's C code, I think it's pretty clear that it can be
very useful.  So really the question is the other way around: what makes
you think that the modules's code will be so vastly different that it
won't want a non-catching funcall, contrary to the experience so far?


        Stefan