Feature request: A way to get a traceback to a buffer or a string

Feature request: A way to get a traceback to a buffer or a string

[Lennart Borgman (gmail)]

In some situations you may know that a function call will cause an 
error. You may then want to get a traceback from this particular call, 
without user intervention. I have attached a macro that can give this. I 
would find it practical if this were included in Emacs.

(defmacro mumamo-get-backtrace (bodyform)
   "Evaluate BODYFORM, return backtrace as a string.
If there is an error in BODYFORM then return the backtrace as a
string, otherwise return nil."
   `(let ((debugger (lambda (&rest debugger-args)
                      (setq debugger-ret (with-output-to-string 
(backtrace)))))
          (debug-on-error t)
          (debug-on-signal t)
          (debugger-ret nil))
      (condition-case err
          (progn
            ,bodyform
            nil)
        (error
         (let* ((errmsg (error-message-string err))
                (debugger-lines (split-string debugger-ret "\n"))
                (dbg-ret (mapconcat 'identity (nthcdr 6 debugger-lines) 
"\n")))
           (concat errmsg "\n" dbg-ret))))))

Re: Feature request: A way to get a traceback to a buffer or a string

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> In some situations you may know that a function call will cause an 
> error. You may then want to get a traceback from this particular call, 
> without user intervention. I have attached a macro that can give this. I 
> would find it practical if this were included in Emacs.
> 
> (defmacro mumamo-get-backtrace (bodyform)
>   "Evaluate BODYFORM, return backtrace as a string.
> If there is an error in BODYFORM then return the backtrace as a
> string, otherwise return nil."
>   `(let ((debugger (lambda (&rest debugger-args)
>                      (setq debugger-ret (with-output-to-string 
> (backtrace)))))
>          (debug-on-error t)
>          (debug-on-signal t)
>          (debugger-ret nil))
>      (condition-case err
>          (progn
>            ,bodyform
>            nil)
>        (error
>         (let* ((errmsg (error-message-string err))
>                (debugger-lines (split-string debugger-ret "\n"))
>                (dbg-ret (mapconcat 'identity (nthcdr 6 debugger-lines) 
> "\n")))
>           (concat errmsg "\n" dbg-ret))))))


The code above does not give a backtrace always, but I think this will:

(defmacro mumamo-get-backtrace-if-error (bodyform)
   "Evaluate BODYFORM, return a list with error message and backtrace.
If there is an error in BODYFORM then return a list with the
error message and the backtrace as a string. Otherwise return
nil."
   `(let* ((debugger
            (lambda (&rest debugger-args)
              (let ((debugger-ret (with-output-to-string (backtrace))))
                ;; I believe we must put the result in a buffer,
                ;; otherwise `condition-case' might erase it:
                (with-current-buffer (get-buffer-create "TEMP GET 
BACKTRACE")
                  (erase-buffer)
                  (insert debugger-ret)))))
           (debug-on-error t)
           (debug-on-signal t))
      (condition-case err
          (progn
            ,bodyform
            nil)
        (error
         (let* ((errmsg (error-message-string err))
                (dbg1-ret
                 (with-current-buffer
                     (get-buffer "TEMP GET BACKTRACE") (buffer-string)))
                ;; Remove lines from this routine:
                (debugger-lines (split-string dbg1-ret "\n"))
                (dbg-ret (mapconcat 'identity (nthcdr 6 debugger-lines) 
"\n"))
                )
           (list errmsg (concat errmsg "\n" dbg-ret)))))))

Re: Feature request: A way to get a traceback to a buffer or a string

[Richard Stallman]

    In some situations you may know that a function call will cause an 
    error. You may then want to get a traceback from this particular call, 
    without user intervention.

Can you explain why this is useful?  I do not see the usefulness.

Re: Feature request: A way to get a traceback to a buffer or a string

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     In some situations you may know that a function call will cause an 
>     error. You may then want to get a traceback from this particular call, 
>     without user intervention.
> 
> Can you explain why this is useful?  I do not see the usefulness.

I have used this in fontification routines to get a backtrace. At least 
on w32 you need to do something like this when you want a backtrace when 
an error happens in a timer.

Is that not the case in Emacs on GNU/Linux?

Re: Feature request: A way to get a traceback to a buffer or a string

[Johan Bockgård]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> I have used this in fontification routines to get a backtrace.

What I usually do is: turn off Font Lock; run font-lock-fontify-buffer.

-- 
Johan Bockgård

Re: Feature request: A way to get a traceback to a buffer or a string

[Stefan Monnier]

>> I have used this in fontification routines to get a backtrace.
> What I usually do is: turn off Font Lock; run font-lock-fontify-buffer.

Same here.  Otherwise I also sometimes turn off font-lock, set
font-lock-support-mode to nil, turn font-lock back on (i.e. keep
font-lock but disable jit-lock).


        Stefan

Re: Feature request: A way to get a traceback to a buffer or a string

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>> I have used this in fontification routines to get a backtrace.
>> What I usually do is: turn off Font Lock; run font-lock-fontify-buffer.
> 
> Same here.  Otherwise I also sometimes turn off font-lock, set
> font-lock-support-mode to nil, turn font-lock back on (i.e. keep
> font-lock but disable jit-lock).


I do that too, but I want to get tracebacks from the users.

Re: Feature request: A way to get a traceback to a buffer or a string

[Richard Stallman]

    I have used this in fontification routines to get a backtrace. At least 
    on w32 you need to do something like this when you want a backtrace when 
    an error happens in a timer.

What is the scenario where you want to get a backtrace when an error
happens in a timer?  Is this something you want during a particular
debugging session when a bug causes an error in that timer function?
So you would insert that macro temporarily just while debugging?

If so, I can see why it is useful, but is this interface the idea one
for the job?  Or would you prefer to have a feature where you could
put a certain timer function's name on a list and then errors in
that timer function would not be caught at all?