[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: Eli Zaretskii
Subject: Re: Dynamic modules: emacs-module.c and signaling errors
Date: Fri, 27 Nov 2015 17:57:19 +0200

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


  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)
       funcall-interactively(eval-last-sexp nil)
       call-interactively(eval-last-sexp nil nil)

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

reply via email to

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