[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: async 1.0
From: |
Samuel Bronson |
Subject: |
Re: async 1.0 |
Date: |
Thu, 5 Jul 2012 15:58:03 -0400 |
On Jul 5, 2012, at 12:09 AM, John Wiegley wrote:
Samuel Bronson <address@hidden> 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?