Eric Abrahamsen <e...@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
