From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: emacs-module.c and signaling errors Date: Thu, 26 Nov 2015 11:36:00 -0500 Message-ID: References: <83k2p7xk13.fsf@gnu.org> <87wpt7p369.fsf@tromey.com> <83d1uzxgvw.fsf@gnu.org> <5654D7CF.90001@cs.ucla.edu> <87si3vox7j.fsf@tromey.com> <56555B52.3030703@cs.ucla.edu> <837fl6xa02.fsf@gnu.org> <5655F10D.9080805@cs.ucla.edu> <83vb8ovkc5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448555780 30676 80.91.229.3 (26 Nov 2015 16:36:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Nov 2015 16:36:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 26 17:36:09 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a1zWh-0007Dz-S1 for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 17:36:08 +0100 Original-Received: from localhost ([::1]:52158 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1zWk-0002lY-4X for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 11:36:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1zWg-0002lT-Oq for emacs-devel@gnu.org; Thu, 26 Nov 2015 11:36:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1zWd-00054U-Jf for emacs-devel@gnu.org; Thu, 26 Nov 2015 11:36:06 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37078) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1zWd-00054F-EC; Thu, 26 Nov 2015 11:36:03 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id tAQGa0Qo016441; Thu, 26 Nov 2015 11:36:01 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id DD3CAAE06E; Thu, 26 Nov 2015 11:36:00 -0500 (EST) In-Reply-To: <83vb8ovkc5.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 26 Nov 2015 17:42:02 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5502=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5502> : inlines <4038> : streams <1544481> : uri <2090050> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195298 Archived-At: > Are you talking about signaling and throwing in case of errors? Yes, that's the only issue at stake. > I think we should be pragmatic here. If there's a way of having an > interface that is safe in the face of the likes of C++ exceptions, > without unduly punishing module authors, we should take it. The interface we expose is a C interface. We could add a C++ interface on top of it, of course, but I think we should first focus on interfacing with C code. > I believe we've already found a reasonably good way to handle > signaling errors and throwing. (I will soon install the changes I > posted yesterday.) With that in place, module code that wants to > signal an error will look very much like what we do in core in similar > situations. The issue at stake is when module code calls an Emacs function that signals an error. In the basic API this signal should not be caught by the module API (i.e. Emacs's Fsignal code will happily longjmp out of the modules code when applicable), unless explicitly requested via something like env->safe_funcall. Stefan