From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Attaching context info to an error Date: Thu, 21 Dec 2023 17:30:24 -0500 Message-ID: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7886"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 21 23:31:39 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rGRZr-0001ql-9B for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Dec 2023 23:31:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rGRYs-0002jZ-6q; Thu, 21 Dec 2023 17:30:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rGRYo-0002hW-N2 for emacs-devel@gnu.org; Thu, 21 Dec 2023 17:30:35 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rGRYm-0004sL-Kb for emacs-devel@gnu.org; Thu, 21 Dec 2023 17:30:34 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0F21910009E; Thu, 21 Dec 2023 17:30:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703197825; bh=61hC2dc7j+U262AQNFaUJReHhM2r+Ia8QwvWikhVlkc=; h=From:To:Subject:Date:From; b=eJyObzUqZ0mlEefjztq+UFzzMZBRZDvYxSeve2ew8Zs79DRkM+wFy9uJfMPw2Gmaf s2PaqQb/eZZnUUJAwRWgI/BxCuQso6yxQkXHLg6VAc+GJdt8USBl1tGF9atRFpsPe0 m2XIHbrEWQ//7oM6ccEikgf13lZ3QJoXIe7No174BiqjCAfZQanGGq3n1EBgqrFm+X fFOC5olWEDNh1sHLjHJxjMt9qBX86gMwKu5swumAgIwCo6uPyJOOGheqeQJfwN7YUQ 91BJu3QCq7ML+pHBY4ajaqtoOkBX8u+mUBtxI/IYctDqm3dmxG08j9WnMj9sy+ysX5 R4WzgC6G1yosA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 462BC10001D; Thu, 21 Dec 2023 17:30:25 -0500 (EST) Original-Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 263A61202DA; Thu, 21 Dec 2023 17:30:25 -0500 (EST) Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314049 Archived-At: I'm playing with `handler-bind` and trying to see how we could make use of such a functionality in Emacs. So far I have encountered basically two use case: - Triggering the debugger. I have patches which use `handler-bind` for that instead of `debug-on-error` in ERT, `eval-expression` and `--debug-init` which circumvent the usual problems linked to (ab)using `debug-on-error`. - I see a potential use in Tramp where we currently use `signal-hook-function` instead. I haven't looked closely enough yet to be sure that it's a good replacement there, tho. - Collecting dynamic context info. This third use case is for thing like `macroexp--with-extended-form-stack` where we'd like to record the `byte-compile-form-stack` that's current when the error is signaled so we can use that info back where we actually catch that error. Similarly when we load a file and that signals an error, we'd like to be able to attach to the error the information that it occurred while loading file FOO (and that could stack up if it occurred while file FOO was loading file BAR). The question is: where should we put this "context" info. One possibility is to do something like the following: (defun load (file ...) (handler-bind ((error (lambda (err) (signal 'error-during-load (cons file err))))) ...)) so an error that occurs during `load` is turned into an `error-during-load` (and those errors contain the original error as well as the relevant file name, the original error could be an `error-during-load` itself, etc...). Similarly the byte-compiler could do (defun byte-compile-blabla (...) ... (condition-case err (handler-bind ((error (lambda (err) (signal 'error-during-bytecomp (cons `byte-compile-form-stack` err))))) ...) (error ;; `err` should now be of the form ;; (error-during-bytecomp STACK ERROR) ...))) but I don't like the idea of changing one kind of error into another. I thought about adding the context info to an auxiliary hash table indexed by the "error object", but that error object tends to be decomposed into "error-name + error-data" and then recomposed fairly liberally, so there's no guarantee that it stays `eq` to itself. Ideally, I'd like to "append it" to the `cdr` of an error object (i.e. the "error data"), but I can't think of a way to do it that's reliable and doesn't introduce nasty backward compatibility issues (and/or require changes in many places). Any other idea how/where we could attach that info? Stefan