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

[sbaugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: sbaugh@catern.com
>> Date: Sat, 10 Feb 2024 19:50:20 +0000 (UTC)
>> Cc: Spencer Baugh <sbaugh@janestreet.com>, 68799@debbugs.gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> > Thanks, this needs a comment explaining why we need condition-case and
>> >> > where does error-message-string come from.
>> >> 
>> >> Actually, on second thought, we could fail anywhere in startup.el, not
>> >> just in server-start.  So should we actually have a wrapper around all
>> >> of normal-top-level which detects an error at startup in a daemon?
>> >
>> > I'd prefer to handle each specific problem specially, to make sure the
>> > error message is self-explanatory.  Also, if the error happens after
>> > the server has been started, there's no reason to forcibly exit.
>> >
>> > So I think we should for now solve this particular issue, and not try
>> > generalizing too much.
>> 
>> To be clear, right now any error anywhere in command-line causes "emacs
>> --fg-daemon" and "emacs --bg-daemon" to hang indefinitely, without
>> printing an error, with no way to ever interact with the Emacs process.
>
> That's not what you said before: you said "anywhere in startup.el",
> which is much more general.  Now you are saying something different.
>
> 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))

>> This error can come from any code, so if we have *any* bugs anywhere in
>> code called from command-line, it will cause Emacs to enter this state.
>
> Why would we assume that *any code* there will signal an error?
> That's like saying that Emacs is a useless program that always signals
> errors in random places.  That's a non-starter here.

We aren't assuming this code in particular will signal an error.  We are
just make this code behave equivalently to other Emacs code, which, when
it throws an error due to a bug, logs that error.

>> We can add good error messages for individual classes of error, but we
>> should also have a catch-all check to make sure that Emacs doesn't enter
>> this broken state if we (or the user) write code which contains a bug.
>
> There's no reason to have a catch-all check where no error is
> expected.  Do you always wrap all of your code in condition-case and
> the likes?  If not, why not?

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.

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.

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

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