Re: async 1.0

[Samuel Bronson]

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?