From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Derek Peschel Newsgroups: gmane.lisp.guile.devel Subject: Evaluating (exit) in the debugger Date: Wed, 19 Nov 2008 16:53:43 -0800 Message-ID: <20081119165343.A29659@eskimo.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1227142437 19130 80.91.229.12 (20 Nov 2008 00:53:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2008 00:53:57 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Nov 20 01:54:59 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L2xox-00083S-Ll for guile-devel@m.gmane.org; Thu, 20 Nov 2008 01:54:59 +0100 Original-Received: from localhost ([127.0.0.1]:39743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2xnp-0001V0-04 for guile-devel@m.gmane.org; Wed, 19 Nov 2008 19:53:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L2xnn-0001Ul-5U for guile-devel@gnu.org; Wed, 19 Nov 2008 19:53:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L2xnl-0001UZ-HK for guile-devel@gnu.org; Wed, 19 Nov 2008 19:53:46 -0500 Original-Received: from [199.232.76.173] (port=46877 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2xnl-0001UW-EP for guile-devel@gnu.org; Wed, 19 Nov 2008 19:53:45 -0500 Original-Received: from ultra5.eskimo.com ([204.122.16.68]:43799) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L2xnk-0003L9-VT for guile-devel@gnu.org; Wed, 19 Nov 2008 19:53:45 -0500 Original-Received: from eskimo.com (eskimo.com [204.122.16.13]) by ultra5.eskimo.com (8.14.3/8.14.0) with ESMTP id mAK0riZ3028477 for ; Wed, 19 Nov 2008 16:53:44 -0800 Original-Received: (from dpeschel@localhost) by eskimo.com (8.9.1a/8.9.1) id QAA01107 for guile-devel@gnu.org; Wed, 19 Nov 2008 16:53:43 -0800 (PST) Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7865 Archived-At: Hi a second time. I'm using Guile 1.8.4, a copy of (ice-9 debugging) from guile 1.8.5, and guile-debugging 0.15. It seems natural to type "e (exit)" at the debug> prompt. Unfortunately the quit exception isn't acted on. Is there any reasonable way to change the debugger? Note the following: - The debugger must catch all exceptions created by evaluated code, not just a list of certain kinds, so it can isolate itself from the effects of the code. - The debugger must use lazy-catch so it can save and show the details of the error. - With regular catch, you can do: (catch #t ;; thunk which returns #f ;; handler which checks the exception type ;; if 'quit, set status (known to the caller of the catch) ;; and return #t ;; otherwise, do the right nonlocal thing ) and the caller of the catch can look at the Boolean and status. The code in (ice-9 boot-9) does exactly this. But that won't work with lazy-catch; if the handler returns the exception is rethrown. - I'm not aware of any syntax for catching all exceptions excluding a list of types. If that syntax existed, I could avoid invoking the lazy- catch handler. The more _un_reasonable solutions I've thought of: - Passing a continuation (which exits when invoked) to the handler. The documentation hints that handlers may invoke any continuation they can get. - Special-case code that lets the rethrow or series of rethrows happen, avoids printing any error messages, and eventually exits. The original quit exception quickly becomes an "unhandled quit exception" exception so the code must deal with that too. Writing a debugger command that calls (exit) was much easier. But that won't solve this problem AFAIK. Thanks, -- Derek