Re: Mail source unreachable - continue yes/no?

[Lars Ingebrigtsen <larsi@gnus.org>]

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.

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

Hey!  I invented Go error handling decades before Go was invented!

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no