Lars Ingebrigtsen <la...@gnus.org> writes: > Eric Abrahamsen <e...@ericabrahamsen.net> writes: > >> `nnmail-get-new-mail' is called from within `gnus-request-scan', and >> there's no error ignoring around `gnus-request-scan' in >> `gnus-get-unread-articles' -- is there? I can't see anything. I would >> propose removing error handling from `nnmail-get-new-mail-1': if the >> fetching of mail sources well and truly fails (and the user hits "no" to >> give up on the process), it should just signal an error up the line. > > Yes, I think so... but isn't there error handling in gnus-request-scan? > I really thought there was...
You mean in `gnus-get-unread-articles', around `gnus-request-scan'? No, there doesn't seem to be. In other places where `gnus-request-scan' is called, the code is mostly working with a single group, in which case you could argue that errors should just bubble up to the user. >> I think nntp servers are louder than the others. When I hit "g" and the >> nntp connection times out, I get a "server closed connection" message, >> and the whole update process halts. > > That sounds like a bug. :-) If I push, for instance > > (nntp "localhost") > > to gnus-secondary-select-methods and hit g, I get an error message and > then the server is marked as "denied", but Gnus carries on its merry > way. (Same if something times out or I hit `C-g' while it's connecting.) I've got my nntp server set in `gnus-select-method', maybe that's why? This has annoyed me off and on for years but I've never taken the time to look into it. My other servers are all localhost nnimap and I never see errors there. I just set debug-on-message appropriately, and will figure out exactly where things are going off.