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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Fri, 27 Nov 2015 11:29:31 -0500
> 
> >   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.

Then maybe you could show the case you were talking about.

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

The count should be based on modules, not on what we have in core.

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

I think module authors won't (and shouldn't) care.