From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Samuel Bronson Newsgroups: gmane.emacs.devel Subject: Re: async 1.0 Date: Thu, 5 Jul 2012 15:58:03 -0400 Message-ID: <6BEF5106-911B-4105-AC76-1F6B1DC17B98@gmail.com> References: <87vcij7rvi.fsf@mithlond.arda> <87r4t7sepa.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1341518297 4957 80.91.229.3 (5 Jul 2012 19:58:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jul 2012 19:58:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: "John Wiegley" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 05 21:58:17 2012 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 1SmsBs-0000O9-3G for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2012 21:58:16 +0200 Original-Received: from localhost ([::1]:49821 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmsBr-0005fL-7Q for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2012 15:58:15 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmsBo-0005fB-Oj for emacs-devel@gnu.org; Thu, 05 Jul 2012 15:58:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmsBm-0006nm-Q9 for emacs-devel@gnu.org; Thu, 05 Jul 2012 15:58:12 -0400 Original-Received: from mail-qa0-f48.google.com ([209.85.216.48]:39549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmsBm-0006mX-JX for emacs-devel@gnu.org; Thu, 05 Jul 2012 15:58:10 -0400 Original-Received: by qadz32 with SMTP id z32so31634qad.0 for ; Thu, 05 Jul 2012 12:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; bh=UXTU95VVMck5pgYpzunKbH0x5mP76R7niKQY02RSP1o=; b=kEBnKm5aGHdkbOu/kzQ4FdvyGi1v4F2yaMsScEv4G9jKPy4NCCVBaT0+tH36FyqP9A 2cSrMe18O1e+fVI9Dk/fH+F8p8QJZj3Jlr4bclbUIBHmrD8lS3Jek7gcBz7ocU4DszcP +64jdZ45pq+8Hg4KcBD+FVf3yiFA7ehNrJ6m3H19u7nm594h6KmO1GN4Z+KoaMVM2IkR BgraluhGVYuKybslm3Ep73cBbevIkKm8W2DGDkxas7ljy76TfeaM847ClPpktJISPxRM /CzQv0/ZHEDBT3QaDgrJw8/g9Alj4O096JyoQpgCbFALJA9H6daA88mAfmKfkliylEtN vGnw== Original-Received: by 10.224.186.143 with SMTP id cs15mr47703100qab.94.1341518288304; Thu, 05 Jul 2012 12:58:08 -0700 (PDT) Original-Received: from [192.168.0.18] (207-172-123-137.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com. [207.172.123.137]) by mx.google.com with ESMTPS id f14sm25731143qak.20.2012.07.05.12.58.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 12:58:07 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.936) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.216.48 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:151441 Archived-At: On Jul 5, 2012, at 12:09 AM, John Wiegley wrote: >>>>>> Samuel Bronson writes: > >> I've long thought Emacs should keep the backtrace along with the >> error/condition/exception (whichever you want to call it), like >> Python does: >> the way things are now is fairly painful even for single-process >> debugging, >> in all but the simplest cases. Captured backtraces would allow the >> user to >> manually examine only those errors that they are actually >> interested in, and >> should permit handlers to augment them with additional information >> before >> re-throwing. > > I agree. Does anybody with experience in this area know how > difficult this > would be to add? I haven't got any experience to speak of, but I did notice that the current API for error/condition handling involves giving handlers a single value of the form (ERROR-SYMBOL . DATA), where ERROR-SYMBOL and DATA are the two things that were passed to `signal'. There is no obvious place to cram an extra BACKTRACE value, and making a new type that acted like a cons but had an extra field would be rather evil... I noticed this while trying to figure out how to get ert.el to report *both* a backtrace *and* the accompanying error message when an error occurs during testing. Right now, it's easy enough to get a backtrace (ert.el already does this using a call to `backtrace' in an `unwind- protect' cleanup) or an error message (just quote/comment out the cleanup)... Oh. I can just remove the "(kill-emacs 2)", I guess? Of course, that changes the exit code for this case to 1, which is meant to indicate test failures, not testing errors. And the backtrace is absurdly long, and comes before the actual error message. I guess there's always the `debugger' variable?