From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Re: saving and restoring the error stack trace Date: Thu, 07 Sep 2006 23:11:47 +0100 Message-ID: <87k64f4998.fsf@ossau.uklinux.net> References: <87veo8av0e.fsf@ossau.uklinux.net> <87psegudr2.fsf@laas.fr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1157667212 8759 80.91.229.2 (7 Sep 2006 22:13:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 7 Sep 2006 22:13:32 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Sep 08 00:13:31 2006 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GLS7g-0002F9-E5 for guile-user@m.gmane.org; Fri, 08 Sep 2006 00:13:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GLS7f-0003qn-QW for guile-user@m.gmane.org; Thu, 07 Sep 2006 18:13:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GLS7b-0003jd-CM for guile-user@gnu.org; Thu, 07 Sep 2006 18:13:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GLS7a-0003gN-8y for guile-user@gnu.org; Thu, 07 Sep 2006 18:13:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GLS7a-0003fl-43 for guile-user@gnu.org; Thu, 07 Sep 2006 18:13:18 -0400 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GLS82-00055F-MH for guile-user@gnu.org; Thu, 07 Sep 2006 18:13:46 -0400 Original-Received: from laruns (host86-129-125-104.range86-129.btcentralplus.com [86.129.125.104]) by mail3.uklinux.net (Postfix) with ESMTP id 3D15540A4D7; Thu, 7 Sep 2006 22:13:17 +0000 (UTC) Original-Received: from laruns (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id 71F5E6F71C; Thu, 7 Sep 2006 23:11:47 +0100 (BST) Original-To: guile-user In-Reply-To: <87psegudr2.fsf@laas.fr> ( =?iso-8859-1?q?Ludovic_Court=E8s's_message_of?= "Fri, 01 Sep 2006 11:39:45 +0200") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:5497 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > Indeed, this exception model is not very convenient. In some cases, > it's even hardly usable, as examplified by the `test-suite/lib.scm' > hacks (use of regexps to parse exception messages and determine their > meaning...). IMO this isn't so bad. Using a regexp to check an exception message makes sense (i) because the message is part of the interface, and so worth checking, and (ii) because there will never be a distinct exception key (or condition type, or whatever) for every possible exception that can be thrown. > Ideally, Guile should use some SRFI-3[56]-like mechanism to represent > exceptions. Unfortunately, I don't think this could be done without > breaking compatibility. Agreed. I've spent some time thinking about this and haven't found a solution yet. > In any case, documenting the exceptions thrown by the built-in > procedures would certainly help. Yes, although I prefer a code solution to a documentation one, if that is possible. Since people seem to like SRFI-35/36, one option would be to provide a procedure that would convert a set of throw args into the closest matching SRFI-35/36 condition. A developer could choose to use this in their handler procs, and then use SRFI-35/36 procedures to interrogate the condition further. If this is possible (which it might not be, because I'm not sure the SRFIs define enough condition types yet), would it be an adequate solution? Regards, Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user