bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#68799: 30.0.50; emacs --fg-daemon fails silently if server-start fails
Date: Sat, 10 Feb 2024 22:05:58 +0200

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

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

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

> To allow users to report bugs that are at all useful, we should at least
> print the error that occurred, even if we don't kill Emacs.

Users aren't supposed to debug Emacs, it's the job of developers.  And
developers know how to run Emacs under a debugger and do any number of
other debugging tricks.  Injecting debugging code into Emacs just
because some of your users did something wrong is not a good idea.  Or
maybe it is -- but we won't know until we understand what exactly goes
wrong in those cases.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]