Announcements and discussions for Gnus, the GNU Emacs Usenet newsreader
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: info-gnus-english@gnu.org
Subject: Re: Mail source unreachable - continue yes/no?
Date: Thu, 14 Oct 2021 11:31:36 -0700	[thread overview]
Message-ID: <874k9jqwzb.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87czo7zw99.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 14 Oct 2021 13:22:26 +0200")

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> On second thought you're not wrong here: the various *-open-server
>> deffoos report their own failures with `nnheader-report' instead of
>> signaling errors, and then `gnus-open-server' swallows any other errors
>> and converts them to messages.
>
> Ah.  I knew there was something like that somewhere.  :-)
>
>> Failures arrived at via `gnus-request-scan' mostly show up as actual
>> errors.
>
> Perhaps we should adjust those errors to be nnheader-report thingies
> instead?
>
>> - When the gnus-open-server deffoo processes fail, they (or their
>>   downstream functions) signal 'gnus-server-connection-error. (I didn't
>>   go through and do this for every backend, just enough to get the
>>   idea.)
>> - Mail source fetching can fail, in which case 'gnus-mail-source-error
>>   is signaled. nnmail.el no longer handles this error: it propagates up
>>   and out through gnus-request-scan.
>
> I've just skimmed the patch, but the approach looks sound to me (in
> general).
>
>> Some observations and questions:
>>
>> - There are many places and depth-levels in Gnus where failure modes are
>>   dealt with as messages (in effect working like `with-demoted-errors')
>>   or as nil return values from functions, which are then converted into
>>   messages, or sometimes even re-signaled as an actual `error' with a
>>   new message string. This often ends up burying real errors, and/or
>>   making debug on error hard to use. We could try flattening this out:
>>   low-level functions signal errors, and only top-level functions in
>>   gnus-start/gnus-group/gnus-sum get to catch them at the last minute,
>>   and only if necessary (other layers can of course catch and re-signal
>>   the errors if some cleanup work needs to be done). I have no idea if
>>   this would end up working out, but I think it would be good to try.
>>   And more use of `condition-case-unless-debug' at the top level.
>
> I doubt it's possible to find an overarching strategy to handle all
> kinds of errors on the "Gnus" level.  Different errors are, well,
> different.

Yeah, I'm trying to decide if it's worth introducing this new approach
at all. I'd hate to put in something that ends up only being useful in
49% of cases, and now there's yet another system that future code readers
have to make sense of.

I'm also not sure it solves enough problems. For instance, I recently
committed something to nnimap.el that cleans up `nnimap-process-buffers'
when an IMAP connection dies. That happens in like three or four
different places. Ideally a signal handling approach would let us do
that cleanup in a single spot -- either an actual single spot, or a
macro we only have to write once. Kind of a generalization of
`nntp-with-open-group', except it catches any instance of
'gnus-server-error, rather than requiring an explicitly-thrown symbol. I
don't quite see that this is feasible right now.

ANYWAY... I sent a patch suggestion for the mail-source problem in a
separate message. I'm kind of waffling on the rest of this custom error
stuff.

In the meantime I got a backtrace on my stop-the-world nntp connection
error, which I've posted below. I guess there's nothing mysterious about
it -- the process dies (I can't tell if it's actually the timeout doing
it or not), and nntp-accept-process-output/nntp-report ends up raising
the error, and there's nothing up the line to catch it. Does this look
surprising or wrong for any reason?


  (if nntp--report-1 (progn (if nntp-record-commands (progn (nntp-record-command "*** CONNECTION LOST ***"))) (throw 'nntp-with-open-group-error t)) (if nntp-record-commands (progn (nntp-record-command "*** CALLED nntp-report ***"))) (nnheader-report 'nntp args) (debug) (apply #'error args))
  nntp-report("Server closed connection")
  nntp-accept-process-output(#<process nntpd>)
  nntp-accept-response()
  #f(compiled-function () #<bytecode -0x16437790137177e>)()
  funcall(#f(compiled-function () #<bytecode -0x16437790137177e>))
  (condition-case nil (funcall bodyfun) (quit (if debug-on-quit nil (nntp-close-server)) (signal 'quit nil)))
  (setq nntp-with-open-group-internal (condition-case nil (funcall bodyfun) (quit (if debug-on-quit nil (nntp-close-server)) (signal 'quit nil))))
  (unwind-protect (setq nntp-with-open-group-internal (condition-case nil (funcall bodyfun) (quit (if debug-on-quit nil (nntp-close-server)) (signal 'quit nil)))) (if timer (progn (cancel-timer timer))))
  (let ((timer (and nntp-connection-timeout (run-at-time nntp-connection-timeout nil #'(lambda nil (let* ... ...)))))) (unwind-protect (setq nntp-with-open-group-internal (condition-case nil (funcall bodyfun) (quit (if debug-on-quit nil (nntp-close-server)) (signal 'quit nil)))) (if timer (progn (cancel-timer timer)))) nil)
  (catch 'nntp-with-open-group-error (nntp-possibly-change-group group server connectionless) (let ((timer (and nntp-connection-timeout (run-at-time nntp-connection-timeout nil #'(lambda nil ...))))) (unwind-protect (setq nntp-with-open-group-internal (condition-case nil (funcall bodyfun) (quit (if debug-on-quit nil (nntp-close-server)) (signal 'quit nil)))) (if timer (progn (cancel-timer timer)))) nil))
  (while (catch 'nntp-with-open-group-error (nntp-possibly-change-group group server connectionless) (let ((timer (and nntp-connection-timeout (run-at-time nntp-connection-timeout nil #'...)))) (unwind-protect (setq nntp-with-open-group-internal (condition-case nil (funcall bodyfun) (quit (if debug-on-quit nil ...) (signal ... nil)))) (if timer (progn (cancel-timer timer)))) nil)) (setq nntp--report-1 nntp-report-n))
  (let ((nntp-report-n nntp--report-1) (nntp--report-1 t) (nntp-with-open-group-internal nil)) (while (catch 'nntp-with-open-group-error (nntp-possibly-change-group group server connectionless) (let ((timer (and nntp-connection-timeout (run-at-time nntp-connection-timeout nil ...)))) (unwind-protect (setq nntp-with-open-group-internal (condition-case nil (funcall bodyfun) (quit ... ...))) (if timer (progn (cancel-timer timer)))) nil)) (setq nntp--report-1 nntp-report-n)) nntp-with-open-group-internal)
  nntp-with-open-group-function(nil "news.gmane.io" nil #f(compiled-function () #<bytecode -0x16437790137177e>))
  nntp-finish-retrieve-group-infos("news.gmane.io" ... 7)
  gnus-finish-retrieve-group-infos((nntp "news.gmane.io") ... 7)
  gnus-read-active-for-groups((nntp "news.gmane.io") ... 7)


  reply	other threads:[~2021-10-14 18:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11  6:07 Lars-Johan Liman
2021-10-12 12:39 ` Lars Ingebrigtsen
2021-10-12 16:50   ` Eric Abrahamsen
2021-10-12 16:57     ` Lars Ingebrigtsen
2021-10-12 17:49       ` Eric Abrahamsen
2021-10-12 17:56         ` Lars Ingebrigtsen
2021-10-12 18:18           ` Eric Abrahamsen
2021-10-12 18:25             ` Lars Ingebrigtsen
2021-10-12 19:50               ` Eric Abrahamsen
2021-10-13 11:33                 ` Lars Ingebrigtsen
2021-10-14  5:03                   ` Eric Abrahamsen
2021-10-14 11:22                     ` Lars Ingebrigtsen
2021-10-14 18:31                       ` Eric Abrahamsen [this message]
2021-10-15 10:42                         ` Lars Ingebrigtsen
2021-10-15 17:43                           ` Eric Abrahamsen
2021-10-12 16:57   ` Lars-Johan Liman
2021-10-14 17:39     ` Eric Abrahamsen
2021-10-15 10:48       ` Lars Ingebrigtsen
2021-10-15 17:52         ` Eric Abrahamsen
2021-10-18  6:42           ` Lars Ingebrigtsen
2021-10-18 15:03             ` Eric Abrahamsen
2021-10-19 13:42               ` Lars Ingebrigtsen
2021-10-19 15:15                 ` Eric Abrahamsen
2021-10-21 23:36               ` Eric Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874k9jqwzb.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=info-gnus-english@gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).