From 754bbf7a25a8dda49b5d08ef0d0443bbf5af0e36 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Sun, 7 Apr 2024 13:41:34 -0500 Subject: new repository --- devdocs/elisp/trapping-errors.html | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 devdocs/elisp/trapping-errors.html (limited to 'devdocs/elisp/trapping-errors.html') diff --git a/devdocs/elisp/trapping-errors.html b/devdocs/elisp/trapping-errors.html new file mode 100644 index 00000000..4e894508 --- /dev/null +++ b/devdocs/elisp/trapping-errors.html @@ -0,0 +1,6 @@ +

Trapping Errors

Emacs normally displays an error message when an error is signaled and not handled with condition-case. While Edebug is active and executing instrumented code, it normally responds to all unhandled errors. You can customize this with the options edebug-on-error and edebug-on-quit; see Edebug Options.

When Edebug responds to an error, it shows the last stop point encountered before the error. This may be the location of a call to a function which was not instrumented, and within which the error actually occurred. For an unbound variable error, the last known stop point might be quite distant from the offending variable reference. In that case, you might want to display a full backtrace (see Edebug Misc).

If you 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.

+

+ Copyright © 1990-1996, 1998-2022 Free Software Foundation, Inc.
Licensed under the GNU GPL license.
+ https://www.gnu.org/software/emacs/manual/html_node/elisp/Trapping-Errors.html +

+
-- cgit v1.2.3