X error handler

X error handler

[Chong Yidong]

Currently, if Emacs receives an X protocol error and x_catch_errors
has not been called, Emacs will kill itself (x_error_handler calls
x_error_quitter, which calls x_connection_closed).  This seems
unnecessary.

Xlib defines two types of X error handlers.  The protocol error
handler (for us, this is x_error_handler) is intended for non-fatal X
protocol errors.  Fatal errors such as losing the connection to the X
server invoke a different handler, the X IO error handler (for us,
this is x_io_error_quitter), which really is supposed to kill Emacs.

Currently, about half the uses of x_catch_errors in Emacs code occur
where we want to make an Xlib call that can produce protocol
errors---we don't want those to kill Emacs, but we don't actually care
about whatever error messages are emitted.  It makes little sense to
go through xmalloc'ing an error message storage stack, etc., for this.

It seems to me cleaner to make the protocol error handler do nothing
by default (rather than kill Emacs).  When x_catch_errors is on, we
can carry out the current behavior, i.e., storing the error string
etc.

Re: X error handler

[Richard Stallman]

    It seems to me cleaner to make the protocol error handler do nothing
    by default (rather than kill Emacs).  When x_catch_errors is on, we
    can carry out the current behavior, i.e., storing the error string
    etc.

This might be a good idea, but I tend to think there must have been
some reason for writing the code originally not to do so.

Can anyone think of a drawback for this?

One possible drawback is that bugs get ignored rather than fixed.
But I am not sure that really matters.

Re: X error handler

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     It seems to me cleaner to make the protocol error handler do nothing
>     by default (rather than kill Emacs).  When x_catch_errors is on, we
>     can carry out the current behavior, i.e., storing the error string
>     etc.
>
> This might be a good idea, but I tend to think there must have been
> some reason for writing the code originally not to do so.
>
> Can anyone think of a drawback for this?
>
> One possible drawback is that bugs get ignored rather than fixed.
> But I am not sure that really matters.

We can always make the default error handler print to stderr when
ENABLE_CHECKING is on.

But since this seems like a non-trivial change, and doesn't fix any
bug, I guess we can put it off till after the release.