42
When C-g doesn't work, you can sometimes get control back with:
pkill -SIGUSR2 emacs
As @Archenoth points out, sending the SIGUSR2 signal to Emacs turns on debug-on-quit. This can be useful, but you'll want to turn it off again at some point (possibly immediately). To do this, call M-x toggle-debug-on-quit.
More information on using SIGUSR1 and SIGUSR2 ...
15
Emacs provides a good amount of debugging facilities including M-x toggle-debug-on-error, M-x toggle-debug-on-quit, debug on signal (which can be used by sending USR2 to Emacs from outside), debug-on-entry (of a function), debug-on-message (when seeing a specific regexp match of a message) and finally, debug itself as alternative to instrumenting a function ...
13
You're looking for signal:
(condition-case err
(call-function)
(error
(cleanup)
(signal (car err) (cdr err)))) ; reraise `err'
10
BTW, an alternative option can be something like:
(let ((error t))
(unwind-protect
(prog1 (call-function)
(setq error nil))
(when error (cleanup))))
The advantage is that you avoid catching&rethrowing the error, which means for example that the debugger will show you the right backtrace (the one that corresponds to the actual source ...
9
No need to read *Messages*. Here's how error handling works in Elisp:
(defun bar ()
(error "asdf"))
(defun foo ()
(condition-case e
(bar)
(error
(message "Caught an error: %S" e))))
9
Two options, neither of which are perfect, come to mind. First, you could wrap most of your early initialization code (ie, before it gets to your customizations) in (ignore-errors ...). If there are errors, however, there won't be a lot of feedback -- ignore-errors will simply return nil.
A more intricate option would be to wrap the potentially buggy code ...
8
@Dan described well how you can turn errors into messages. You can
also do whatever you want with errors by using
condition-case.
Yet another option is to use
unwind-protect.
I’ll stick to condition-case here, for no reason whatsoever.
Catching the Error
This should always guarantee your key definitions get evaluated,
regardless of what happened inside ...
7
This is fixed in Emacs 25, where you can use the make-process function with the :stderr argument. I don't think there's anything suitable in Emacs 24.
6
It looks like visible-bell mode is enabled. This means that whenever an Emacs command rings a bell (i.e. fails in some way), it will try to flash the screen.
You should be able to turn it off with (setq visible-bell nil).
Flickering is annoying, but the bell gives you useful information so I wouldn't want to suppress it completely. You can customize ...
5
Try:
(condition-case err
(potentially-too-recursive-function)
(error (message "error=%S, data=%S" (car err) (cdr err))))
This will not only catch the error but will additionally emit a message telling you which specific error was signaled. Also, in recent Emacsen, you can use completion to see the possible error symbols.
Sadly, when you try the ...
5
The error in question is thrown with user-error, not simply echoed with message.
In your particular case testing the return value of evil-get-marker should work also:
(if (evil-get-marker ?8)
(evil-goto-mark ?8)
(evil-set-marker ?8))
5
The documentation for the customisable variable byte-compile-error-on-warn says:
If true, the byte-compiler reports warnings with `error'.
4
I don't think that input validation of top-level widgets happens automatically. Neither the info manual nor the source code suggest otherwise.
Composite widgets (e.g. editable-list) automatically validate their childs upon validation, but you need to explicitly validate top-level widgets yourself before using their values.
For instance, if your form has ...
4
debug-on-error, and more generally the debugger, are not available for errors raised from post-command-hook (for example, to prevent runaway recursion).
What you can do is what programmers have done from Day One: print information. But before you do that, bisect the list of functions that you have on post-command-hook, narrowing the problem down to ...
4
Not exactly sure what the context is or what you mean.
If by "open a window with an error" and "opening error buffer" you mean opening the debugger in buffer *Backtrace*, then set variable debug-on-error to nil to prevent that. The error message will then simply be shown in the echo area.
Variable visible-bell controls whether a bell (ding) sound is heard ...
4
Maybe because it's 2018 now, but in my case,
I only had to turn on debugging like wasamasa suggested:
M-x toggle-debug-on-error
After this, M-x eval-buffer on my faulty Elisp file
gave context by providing the position of the error,
like this:
Debugger entered--Lisp error: (invalid-read-syntax ")")
eval-buffer() ; Reading at buffer position 523
...
4
That looks fine, except that I'd use (fboundp 'define-error) instead of testing the version number.
Until Emacs-24.3 what was used instead were manual calls to put as in:
(put 'foo-error 'error-conditions '(foo-error error))
(put 'foo-error 'error-message "Foo on you!")
4
It also sometimes helps to abort-recursive-edit with C-].
4
You can use whatever you think is most appropriate for your context. There is no "right" way for all contexts.
message does not prevent continued processing of the current command. If you want to be sure the user sees the message, you can use sit-for or sleep-for (which see).
You can pop up a window, frame, or tooltip with a message. Like message, this ...
4
See this issue. This problem should be fixed in the next release.
Quick fix:
Change the function insert-string to insert in ~/.emacs.d/core/core-spacemacs-buffer.el, and everything works well.
3
If the function your are calling really echoes a message, you can use (current-message).
Return the string currently displayed in the echo area, or nil if
none.
Of course, it would be better to issue an error, see other answer for more details on this.
3
You must define the symbol as an error first:
(define-error 'my-error "Custom error")
(condition-case err
(signal 'my-error 'my-data)
(my-error (message "data: %S" err)))
Evaluating this form yields "data: (tmp:error . my-data)" as expected.
3
This appears to be coming from the function org-flag-drawer.
Use C-h f to find where this function is defined, and modify it to also give the buffer name:
(defun org-flag-drawer (flag)
"When FLAG is non-nil, hide the drawer we are within.
Otherwise make it visible."
(save-excursion
(beginning-of-line 1)
(when (looking-at "^[ \t]*:[a-zA-Z][a-...
3
The docstring for condition-case (C-h f condition-case) says:
condition-case is a special form in `C source code'.
(condition-case VAR BODYFORM &rest HANDLERS)
Regain control when an error is signaled.
Executes BODYFORM and returns its value if no error happens.
Each element of HANDLERS looks like (CONDITION-NAME BODY...)
where the ...
3
You didn't raise an error with your error message. You just used message.
So your message actually appeared (check buffer *Messages*), but then execution continued and the second message was displayed.
If you want to stop execution when the error occurs then you need to raise another error. E.g.:
(defun my-divide-by-0 ()
(condition-case nil
(/ 1 ...
3
You can wrap that in ignore-errors, to ignore any error evaluating it might raise:
(ignore-errors (require-package 'clips-mode))
If you want to ignore only particular errors then you can instead wrap it with condition-case:
condition-case is a special form in C source code.
(condition-case VAR BODYFORM &rest HANDLERS)
Regain control when ...
3
Your error symbol test-signal is not defined. C-h f signal says:
An error symbol is a symbol with an error-conditions property
that is a list of condition names.
Let's check this for some standard error symbols and the test-signal
(get 'error 'error-conditions)
;; => (error)
(get 'args-out-of-range 'error-conditions)
;; => (args-out-of-range ...
2
The error message tells you where the error is: position 23740. You can go there with goto-char. Doing M-x goto-char 23740 will take you to the error. org-mode's folding may make it hard to see what's going on, so switching to fundamental-mode (with M-x fundamental-mode) first may help you see what's going on.
2
The other answers have pretty well covered the low-level error-handling facilities that will be useful in a case like this. Another approach that can help is modularity. For instance, I divide my initialization file into several different files (using provide as appropriate), and I load them using this function instead of require:
(defun my/require-softly ...
2
Write an infinite loop, and catch the error outside the loop.
(condition-case nil
(while t
(org-move-subtree-up))
(error nil))
Org mode 7.8.11 throws a plain error for this message. If you have a more recent version that calls user-error instead of error, replace error by user-error.
This hides all errors. It would be safer to catch only the ...
Only top voted, non community-wiki answers of a minimum length are eligible
