Error does not throw to debugger in 'when' block

Error does not throw to debugger in 'when' block

[Arthur Miller]

When running this little code, I have observed that 'error' does not end in
debugger:

(defun new-patch (&optional patch-name)
  (interactive "sPatch name: ")
  (let ((path (expand-file-name patch-name)))
    (message "PATH: %s" path)
    (when (file-exists-p path)
      (error "A worktree with this name already exists"))))

If I run this code, I see it correctly executes error, but it does not open
debugger. If I place cursor after the error form, debugger is
opened. Value of debug-on-error is 't.

This is output in *Messages* buffer for 'Emacs -Q':

PATH: /home/arthur/repos/emsrc/28.2
progn: A worktree with this name already exists
Mark set [2 times]

Just curious, is this intended new behaviour for 'error' or a bug?

Re: Error does not throw to debugger in 'when' block

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Thu, 12 Jan 2023 07:51:01 +0100
> 
> When running this little code, I have observed that 'error' does not end in
> debugger:
> 
> (defun new-patch (&optional patch-name)
>   (interactive "sPatch name: ")
>   (let ((path (expand-file-name patch-name)))
>     (message "PATH: %s" path)
>     (when (file-exists-p path)
>       (error "A worktree with this name already exists"))))
> 
> If I run this code, I see it correctly executes error, but it does not open
> debugger. If I place cursor after the error form, debugger is
> opened. Value of debug-on-error is 't.
> 
> This is output in *Messages* buffer for 'Emacs -Q':
> 
> PATH: /home/arthur/repos/emsrc/28.2
> progn: A worktree with this name already exists
> Mark set [2 times]
> 
> Just curious, is this intended new behaviour for 'error' or a bug?

How exactly do you "run this code"?  The details matter.

Re: Error does not throw to debugger in 'when' block

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Thu, 12 Jan 2023 07:51:01 +0100
>> 
>> When running this little code, I have observed that 'error' does not end in
>> debugger:
>> 
>> (defun new-patch (&optional patch-name)
>>   (interactive "sPatch name: ")
>>   (let ((path (expand-file-name patch-name)))
>>     (message "PATH: %s" path)
>>     (when (file-exists-p path)
>>       (error "A worktree with this name already exists"))))
>> 
>> If I run this code, I see it correctly executes error, but it does not open
>> debugger. If I place cursor after the error form, debugger is
>> opened. Value of debug-on-error is 't.
>> 
>> This is output in *Messages* buffer for 'Emacs -Q':
>> 
>> PATH: /home/arthur/repos/emsrc/28.2
>> progn: A worktree with this name already exists
>> Mark set [2 times]
>> 
>> Just curious, is this intended new behaviour for 'error' or a bug?
>
> How exactly do you "run this code"?  The details matter.

Just pasted the above defun in scratch buffer, in emacs with -Q option, then
C-x C-e, and run with M-x. Nothing special.

I have observed later, that it correctly exits from the execution of defun, if I
add more code after the 'when' form. It just does not end up in the debug buffer.

I am ok with the new behavior, I think it is probably more handy, was just
surprised, haven't noticed it before.

The Emacs used was built today from the lastest master, maybe a couple of hors
before I posted this message.

Re: Error does not throw to debugger in 'when' block

[Michael Heerdegen]

Arthur Miller <arthur.miller@live.com> writes:

> Just pasted the above defun in scratch buffer, in emacs with -Q option, then
> C-x C-e, and run with M-x. Nothing special.
>
> I have observed later, that it correctly exits from the execution of
> defun, if I
> add more code after the 'when' form. It just does not end up in the
> debug buffer.

It's still unclear from your words what you do and what you expect.

For M-x new-patch to enter the debugger you need to enable
`debug-on-error'.  I see the expected behavior: I get a debugger when
the option is enabled.

For C-x C-e you need to eval a form that raises an error.  Also that
works as expected: evaluating the defun doesn't raise an error as
expected.

Michael.

Re: Error does not throw to debugger in 'when' block

[Arthur Miller]

Michael Heerdegen <michael_heerdegen@web.de> writes:

Let's just do the part that matters:

> For C-x C-e you need to eval a form that raises an error.  Also that
> works as expected: evaluating the defun doesn't raise an error as
> expected.

Yes of course. As Eli said details matters.

I have now looked more into it, tested another example, and I do understand now
what happeneds; I just didn't know it worked that way:

When called interactively with M-x, (as the command) the evaluation of the
function exits on error, the error message is emittied, but the evaluation is
not trapped in the debugger. When called from lisp, for example via: M-: it
ends up in the debugger. I was calling it interactively, and didn't realize
realized it worked this way. I wasn't aware that "commands" does not trap in the
debugger on errors. Maybe I need to set some other of debug-on-* flags?
Actually, I am happy as it is, I was just curious about what happened since I
expected something else.

It was my bad to run it as a command, but I didn't know it worked that way.
I took a look into manual, parts about about Debugging, command loop,
interactive call and defining commands, using interactve, as well as in  help
for error, and I don't see it mentioned anywhere.

Anyway, thanks; I have learned that one now :).
/arthur

Re: Error does not throw to debugger in 'when' block

[Michael Heerdegen]

Arthur Miller <arthur.miller@live.com> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> Let's just do the part that matters:
>
> > For C-x C-e you need to eval a form that raises an error.  Also that
> > works as expected: evaluating the defun doesn't raise an error as
> > expected.
>
> Yes of course. As Eli said details matters.
>
> I have now looked more into it, tested another example, and I do
> understand now
> what happeneds; I just didn't know it worked that way:
>
> When called interactively with M-x, (as the command) the evaluation of the
> function exits on error, the error message is emittied, but the
> evaluation is
> not trapped in the debugger. When called from lisp, for example via: M-: it
> ends up in the debugger. I was calling it interactively, and didn't realize
> realized it worked this way. I wasn't aware that "commands" does not
> trap in the
> debugger on errors. Maybe I need to set some other of debug-on-* flags?

Only debug-on-error.  That's what I tested.  I enabled that option and
called your command in the original form and got a debugger.

[ Note there is a pitfall: M-: debug-on-error RET prints t although the
variable's value "is actually" nil - that's because M-: binds the variable
to t temporarily when evaluating the specified expression. ]


Michael.

Re: Error does not throw to debugger in 'when' block

[Arthur Miller]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Michael Heerdegen <michael_heerdegen@web.de> writes:
>>
>> Let's just do the part that matters:
>>
>> > For C-x C-e you need to eval a form that raises an error.  Also that
>> > works as expected: evaluating the defun doesn't raise an error as
>> > expected.
>>
>> Yes of course. As Eli said details matters.
>>
>> I have now looked more into it, tested another example, and I do
>> understand now
>> what happeneds; I just didn't know it worked that way:
>>
>> When called interactively with M-x, (as the command) the evaluation of the
>> function exits on error, the error message is emittied, but the
>> evaluation is
>> not trapped in the debugger. When called from lisp, for example via: M-: it
>> ends up in the debugger. I was calling it interactively, and didn't realize
>> realized it worked this way. I wasn't aware that "commands" does not
>> trap in the
>> debugger on errors. Maybe I need to set some other of debug-on-* flags?
>
> Only debug-on-error.  That's what I tested.  I enabled that option and
> called your command in the original form and got a debugger.
>
> [ Note there is a pitfall: M-: debug-on-error RET prints t although the
> variable's value "is actually" nil - that's because M-: binds the variable
> to t temporarily when evaluating the specified expression. ]
>
Aha :) Now you say something. Yes that seems to be the case. I have checked
Customize now, and that indeed was off. I was always thought I had
debug-on-error to be always on. I obviously didn't. When I checked it's value I
did from within M-:, so that explains it. I should have checked with C-h v
instead or looked in Customize (which I barely ever use). When I have explicitly
set it debug-on-error to 't now it works same even with interactive commands, it
ends in debugger.

What a small thing can take such a long time. If I just checked with C-h v
instead.

I didn't know M-: let-bind the error-on-debug, so thanks for the kind
explanation on that one!

Best regards
/arthur