Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii <eliz@gnu.org>]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Paul Eggert <eggert@cs.ucla.edu>,  Emacs-devel@gnu.org
> Date: Sun, 03 Jan 2016 13:45:15 -0800
> 
> So, on a detected crash, auto-save all files, and save a text file with the
> crash data before exiting? That sounds pretty safe and reasonable to me.

Which is why we already do that.  See shut_down_emacs.

> Maybe we could even popup a window to alert the user, and prompt them to press
> a key, but the only action will be to exit (unless the user is a power user
> and uses recursive edit to attempt to interact with their now-broken Emacs).

We already do that as well, as part of so-called "emergency exit".
See handle_interrupt.

> Why must it be all or nothing? Some is better than nothing. The error handler
> can evolve after we know just how useful it is (or whether it is).

That's exactly the crux of our disagreement with Daniel: we think
partial recovery is better (for users) than no recovery, while he
thinks that no recovery is better (because it makes the job of
debugging easier).

> Eli, Paul: What do you think about just auto-saving as much as possible,
> writing an error trace to a file, and prompting the user to press a key, after
> which we abort the running Emacs?

We already do all that, we just don't prompt in most cases.  We simply
auto-save and then commit suicide.  But in the case of stack overflow,
we can do better, so we try that as well.

> This is in line with what many of my OS X applications do when they
> encounter a fatal error; they're kind enough to tell me that it
> happened, and give me an "OK" button to click before they abort, but
> they don't allow me to continue to operate the application in an
> unknown state.

On MS-Windows, when we abort or succeed in catching a fatal signal
early enough, we also pop up an abort dialog, which even allows to
attach a debugger, not just exit.

IOW, all of these reasonable things we already do.  The argument is
not about them, it's about going some extra mile in the specific case
of stack overflow.  In that case, we can do better in most cases:
avoid crashing entirely, leaving Emacs in a state where the user can
shut down the session in a more orderly fashion.  Admittedly, this
won't work in all cases, but that's not required.