(lispref.info)Error Debugging


Next: Infinite Loops Up: Debugger

Entering the Debugger on an Error
---------------------------------

   The most important time to enter the debugger is when a Lisp error
happens.  This allows you to investigate the immediate causes of the
error.

   However, entry to the debugger is not a normal consequence of an
error.  Many commands frequently get Lisp errors when invoked in
inappropriate contexts (such as `C-f' at the end of the buffer) and
during ordinary editing it would be very unpleasant to enter the
debugger each time this happens.  If you want errors to enter the
debugger, set the variable `debug-on-error' to non-`nil'.

 - User Option: debug-on-error
     This variable determines whether the debugger is called when a
     error is signaled and not handled.  If `debug-on-error' is `t', all
     errors call the debugger.  If it is `nil', none call the debugger.

     The value can also be a list of error conditions that should call
     the debugger.  For example, if you set it to the list
     `(void-variable)', then only errors about a variable that has no
     value invoke the debugger.

   To debug an error that happens during loading of the `.emacs' file,
use the option `-debug-init', which binds `debug-on-error' to `t' while
`.emacs' is loaded.

   If your `.emacs' file sets `debug-on-error', the effect lasts only
until the end of loading `.emacs'.  (This is an undesirable by-product
of the `-debug-init' feature.)  If you want `.emacs' to set
`debug-on-error' permanently, use `after-init-hook', like this:

     (add-hook 'after-init-hook
               '(lambda () (setq debug-on-error t)))


automatically generated by info2www