bug#33782: 27.0.50; Emacsclient ignores errors when its frame is deleted

bug#33782: 27.0.50; Emacsclient ignores errors when its frame is deleted

[Philipp]

Assuming an Emacs server is running:

$ emacsclient --create-frame --eval '(unwind-protect (error "foo") (delete-frame))' ; echo $?
0

This means that if the frame created by Emacsclient is deleted, errors
are ignored.  This seems like a bug; I wouldn't expect errors to be
ignored in this case, because they should bubble up through the
`unwind-protect' form.


In GNU Emacs 27.0.50 (build 70, x86_64-pc-linux-gnu, GTK+ Version 3.22.24)
 of 2018-12-17
Repository revision: 55838e4e6a176317367c6759e0520395e80c856f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Debian GNU/Linux buster/sid

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --enable-gtk-deprecation-warnings
 --enable-gcc-warnings=warn-only --with-modules --without-pop
 --with-mailutils --enable-checking --enable-check-lisp-object-type
 'CFLAGS=-O0 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY GNUTLS
FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS
JSON GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec epa derived epg epg-config
gnus-util rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst pcase ffap
thingatpt url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map url-vars subr-x rx gnutls puny
seq byte-opt gv bytecomp byte-compile cconv dbus xml cl-loaddefs cl-lib
elec-pair mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 109268 7603)
 (symbols 48 21807 1)
 (strings 32 32891 1767)
 (string-bytes 1 890386)
 (vectors 16 16545)
 (vector-slots 8 535263 7864)
 (floats 8 51 66)
 (intervals 56 224 0)
 (buffers 992 12))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

If you received this communication by mistake, please don’t forward it to
anyone else (it may contain confidential or privileged information), please
erase all copies of it, including all attachments, and please let the sender
know it went to the wrong person.  Thanks.

bug#33782: 27.0.50; Emacsclient ignores errors when its frame is deleted

[Lars Ingebrigtsen]

Philipp <p.stephani2@gmail.com> writes:

> Assuming an Emacs server is running:
>
> $ emacsclient --create-frame --eval '(unwind-protect (error "foo") (delete-frame))' ; echo $?
> 0
>
> This means that if the frame created by Emacsclient is deleted, errors
> are ignored.  This seems like a bug; I wouldn't expect errors to be
> ignored in this case, because they should bubble up through the
> `unwind-protect' form.

Well...  like

(unwind-protect (error "foo") (message "zot"))

there's no error bubbling, and there's no error to be returned, so I
think this is correct behaviour?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33782: 27.0.50; Emacsclient ignores errors when its frame is deleted

[Noam Postavsky]

reopen 33782
tags 33782 - notabug
quit

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philipp <p.stephani2@gmail.com> writes:
>
>> Assuming an Emacs server is running:
>>
>> $ emacsclient --create-frame --eval '(unwind-protect (error "foo") (delete-frame))' ; echo $?
>> 0
>>
>> This means that if the frame created by Emacsclient is deleted, errors
>> are ignored.  This seems like a bug; I wouldn't expect errors to be
>> ignored in this case, because they should bubble up through the
>> `unwind-protect' form.
>
> Well...  like
>
> (unwind-protect (error "foo") (message "zot"))
>
> there's no error bubbling, and there's no error to be returned, so I
> think this is correct behaviour?

No, that's incorrect, unwind-protect doesn't catch errors, it just
executes the handler forms (in this case (message "zot")) before the
error finishes bubbling.

bug#33782: 27.0.50; Emacsclient ignores errors when its frame is deleted

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

>>> $ emacsclient --create-frame --eval '(unwind-protect (error "foo")
>>> (delete-frame))' ; echo $?
>>> 0
>>>
>>> This means that if the frame created by Emacsclient is deleted, errors
>>> are ignored.  This seems like a bug; I wouldn't expect errors to be
>>> ignored in this case, because they should bubble up through the
>>> `unwind-protect' form.

[...]

> No, that's incorrect, unwind-protect doesn't catch errors, it just
> executes the handler forms (in this case (message "zot")) before the
> error finishes bubbling.

Yes, but there is no...  bubbling...  in this context.  The code is the
moral equivalent of saying

emacs -Q -nw --eval '(unwind-protect (error "foo") (kill-emacs))'; echo $?

in an emacsclient context, and this which also says "0".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33782: 27.0.50; Emacsclient ignores errors when its frame is deleted

[Noam Postavsky]

tags 33782 notabug
close 33782
quit

Lars Ingebrigtsen <larsi@gnus.org> writes:

>>>> $ emacsclient --create-frame --eval '(unwind-protect (error "foo")
>>>> (delete-frame))' ; echo $?
>>>> 0

> Yes, but there is no...  bubbling...  in this context.  The code is the
> moral equivalent of saying
>
> emacs -Q -nw --eval '(unwind-protect (error "foo") (kill-emacs))'; echo $?
>
> in an emacsclient context, and this which also says "0".

Oh, I see, for emacsclient --create-frame, delete-frame is like
kill-emacs.  I guess that makes sense then.  Re-closing.