On Sat., Jan. 18, 2020, 21:07 tim Rowledge, <tim@rowledge.org> wrote:

> On 2020-01-18, at 1:55 PM, Jakob Reschke <forums.jakob@resfarm.de> wrote:

That weirdly fails. As in, I can open a browser on it. I can try to open an ftp client on it with
`FTPClient openOnHostNamed: 'ftp.us.debian.org'`
and it worked one time but still failed to work in the FileBrowser, but never again. It simply fails to resolve the name to an IP. The one time it did resolve the response message was rather sternly telling people not to use it!

To make it more fun we get a not terribly amusing un-endable cycle of a notifier telling me that 'Could not resolve the server named:' etc, which is the default action of a NameLookupFailure signal. If you 'give up' you then go on to another error (somebody should be catching that 'give up' state) and when using the FileBrowser that results in another cycle because the ServerDirectory>>#wakeUp method gets run again and again and again, each time finding in ServerDirectory>>#openFTPClient that 'client' is nil and so trying to open the connection and... weren't we just here?

So again with two errors

a) for some reason the host name won't resolve (usually)

b) some better error handling is needed between the file browser, ServerDirectory and FTPClient. There has to be some balance between trying and retrying to connect and deciding it isn't going to work and forgetting about it. I'm not sure where that balance should lie in order to be both helpful and not infuriating. Certainly it's more than a bit irritating right now.

https://tech.labs.oliverwyman.com/blog/2011/01/04/try-again-with-exceptions/ might help.


tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
"Both.." said Pooh, as the guillotine came down