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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Fri, 27 Nov 2015 10:15:49 -0500
> 
> >> You mean debug-on-error will properly show me the right stack state and
> >> let me look up and change the corresponding variables?
> > Up to the C level, yes.  You cannot do that once you get to the C
> > level, not with the Lisp debugger we have.
> 
> 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)

> >> 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.  If there's no real need for this
functionality, then there's no harm in not providing it.