bug#68799: 30.0.50; emacs --fg-daemon fails silently if server-start fails

[Eli Zaretskii <eliz@gnu.org>]

> From: sbaugh@catern.com
> Date: Sat, 10 Feb 2024 23:23:19 +0000 (UTC)
> Cc: 68799@debbugs.gnu.org, sbaugh@janestreet.com
> 
> > What exactly is meant by "anywhere in command-line"? the function
> > command-line in startup.el? or something else?
> 
> The function command-line in startup.el.
> 
> Or, more specifically: anywhere during the evaluation of the form in the
> variable top-level, which by default is (normal-top-level).  (which
> calls (command-line))

Some of that code already detects errors and takes appropriate
actions.  I'm okay with augmenting the existing error-detecting code
in startup.el with daemon-specific actions, if what we do now is not
TRT for the daemon invocations.  I'm also okay with identifying more
places where error detection and recovery is needed, perhaps only in
the daemon case.  But that must be on a case by case basis, based on
clear understanding what could be the reasons and the effects of those
reasons.  I'm not interested in "catch-all" dumb processing of startup
errors without understanding them, because the recovery code will then
not necessarily be correct and on target.

> The reason to have a catch-all is what I just said: if there's an error
> in this code, either caused by the user or from a bug in the code, it
> causes Emacs to silently hang without logging an error, providing
> absolutely no way for the user to know what's going wrong.

Not true, at least not in all cases.  Once again, the only way to make
progress here that I agree to is one case at a time, based on
understanding the possible reasons and on what we want Emacs (daemon
or not) do in each case.

> You might as well ask why we have a condition-case wrapped around
> command_loop_1 which calls cmd_error, instead of just discarding the
> error and continuing.

The reason for doing it with command_loop_1 is well known, and is not
really relevant to this discussion.

> >> I have concrete reasons to want this: I think there's a bug in
> >> command-line in trunk which some of my users using emacs --daemon have
> >> run into.  But I have zero information about what caused the bug,
> >> because Emacs just hangs without printing any error message in this
> >> case.
> >
> > Then please debug that, and let's talk when you do have concrete data.
> 
> I can't debug that because I can't reproduce it and the failure case
> leaves no information behind.  That's part of the point of why we should
> log on error.

It's okay for you to add code locally to the relevant parts that would
log the necessary information, so you can understand what happens.
Please get back after you understand what went wrong, and we can then
discuss whether such situations could happen with others, and whether
and how to handle them.

> Your argument here justifies silencing all errors in Emacs and never
> writing them to *Messages*.  That's obviously absurd...

Yes, so let's not go "ad absurdum".