22.4.7 Trapping Errors

An error may be signaled by subroutines or XEmacs Lisp code. If a signal is not handled by a condition-case, this indicates an unrecognized situation has occurred. If Edebug is not active when an unhandled error is signaled, debug is run normally (if debug-on-error is non-nil). But while Edebug is active, debug-on-error and debug-on-quit are bound to edebug-on-error and edebug-on-quit, which are both t by default. Actually, if debug-on-error already has a non-nil value, that value is still used.

It is best to change the values of edebug-on-error or edebug-on-quit when Edebug is not active since their values won’t be used until the next time Edebug is invoked at a deeper command level. If you only change debug-on-error or debug-on-quit while Edebug is active, these changes will be forgotten when Edebug becomes inactive. Furthermore, during Edebug’s recursive edit, these variables are bound to the values they had outside of Edebug.

Edebug shows you the last stop point that it knew about before the error was signaled. This may be the location of a call to a function which was not instrumented, within which the error actually occurred. For an unbound variable error, the last known stop point might be quite distant from the offending variable. If the cause of the error is not obvious at first, note that you can also get a full backtrace inside of Edebug (see Edebug Misc).

Edebug can also trap signals even if they are handled. If debug-on-error is a list of signal names, Edebug will stop when any of these errors are signaled. Edebug shows you the last known stop point just as for unhandled errors. After you continue execution, the error is signaled again (but without being caught by Edebug). Edebug can only trap errors that are handled if they are signaled in Lisp code (not subroutines) since it does so by temporarily replacing the signal function.