Re: Mail source unreachable - continue yes/no?

[Eric Abrahamsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I put plain old calls to `error' inside `nnimap-request-scan', and that
>> also derailed the "g" update process. So whatever handling there once
>> was either is not around this particular piece of code, or else it might
>> have gone away at some point.
>
> Yeah, perhaps it went missing at some point.
>
>> Are you likely to recall further how this once worked? :) I can start
>> sketching out some custom errors, otherwise.
>
> I'm not sure about anything.  I do recall (in the olden days) getting a
> humongous appended error message from all the backends if the network
> went down or something, though.

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.

Failures arrived at via `gnus-request-scan' mostly show up as actual
errors.

I still haven't looked into why nntp-connection-timeout ends up
interrupting everything.

> Custom errors sound good, though.

Okay, here's a _very_ rough first sketch. There are a handful of errors
defined, mostly for connection problems. I didn't do any handling for
authentication failures, because that's a fairly distinct system, and
I'm not sure there's any need to mess with it (I haven't tested what
auth failures do to Gnus update), anyway that can be left for later.

A few things happen in this patch:

- 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.
- There are `condition-case' wrappers in `gnus-get-unread-articles' now,
  which seems to be the main place where it's important not to interrupt
  a larger loop. Most other places the user is just "doing one thing",
  and it seems okay to let the error reach them directly.

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.

- There are many ways of logging, and messaging the user. Apart from
  `message' itself, there's `nnheader-report', `gnus-backend-trace',
  `nnheader-message(-maybe)', `gnus-message' and its action message log,
  along with `gnus-final-warning' and `gnus-error'.

  nnheader-report, in particular, seems to often be used as a substitute
  for actually signaling an error. A server is asked to do something, it
  fails for some reason and logs the reason with nnheader-report, then
  returns nil. The caller sees the nil, then retrieves the string with
  nnheader-get-report, and uses it to signal an error.

  I'm not claiming to have thought this through completely, much less
  tested anything, but I wonder if in most cases the underlying code
  couldn't just signal an error directly.

- Lastly, I wanted to try out the warning facilities here, just to see
  if they might provide a good tool.
  nnheader-message/gnus-message/gnus-error could dispatch to
  display-warning.

Anyway, those are some thoughts that occurred while poking around with
this.

gnus-define-errors.diff
Description: Text Data