id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
268	add error indicators to Reconnector	Brian Warner		"For Tahoe, it'd be nice to let the user know *why* certain storage server connections could not be established. We recently added connection handlers, which makes it possible for a tahoe client to be configured to never connect over plain TCP (always routing such hints over Tor instead). If Tor is unavailable, some FURLs won't be connectable, and unlike normal server-not-responding errors, the corrective action is for the *local* user to install Tor.

For one-shot `Tub.getReference()` calls, we currently signal this with a `NoLocationHintsError` (although we should add some more details to the exception's text argument). But for `Tub.connectTo()`, there's no error indication: the callback is fired each time a connection is established, but nothing ever indicates an error, so there's no pathway to deliver the information that a functional connection-handler could not be found.

Unfortunately the `*args` and `**kwargs` of `Tub.connectTo` are already claimed (they are passed through to the callback function). So I think we'll need a new API method. I'm thinking that it should take both callback and errback arguments (each just a single callable, and obligate the user to write a `lambda x:` if they want additional arguments). Then the callback would be fired upon successful connection as before, but the new errback would be fired (with a Failure) each time the connection attempt failed.

Then Tahoe's server-status page could remember the message from the last time the errback was called, and display it on the status page until the callback() fires to replace it.

Then I think we should expand the set of exceptions a little bit, so there's enough information for Tahoe to e.g. realize that the FURL contained only a TCP hint but it'd been configured to ignore them.
"	enhancement	closed	major	0.12.5	network	0.12.3	fixed