Fail Gracefully on deep query errors

[smith]

Doing a whois query to a domain with the gooddomains.com registrar raises:

Whois::ConnectionError: SocketError: getaddrinfo: nodename nor servname provided, or not known

Because when doing the registrar lookup to whois.gooddomains.com the address does not resolve.

Should errors like these (where the advertised whois server address does not resolve) be rescued so we can still have a record with the registrar data?

[weppos]

This feature was requested in GH-112 and discussed in several other issues, including GH-47. This is something I have been thinking to work on for a while, but never had the time to do that.

Basically, my idea was to be able to provide an option to limit the query dept (normally you might want to limit it to 1, since AFAIK no query goes further than 2 steps).

Also, it would be cool to be able to access partial responses in case of failure.

Honestly, I think we are talking about two different features that are closely related each other.

[smith]

I think #47 is closer to what's going on here, though both items would be useful. The problem here is that we're assuming (and you would think that the whois server reported by the registry would at least be a an address that can resolve) that the whois server is a valid address.

IMO we should rescue from this particular error and return false from extract_referral. I wouldn't consider this a temporary exception; if a registrar of all people can't have an address that resolves that tells me all I need to know.

However, a connection might behave the same way if your DNS wasn't responding (or with no network connection at all), but if a lookup for the registry succeeds immediately following a failure by the registrar that probably isn't the case.

[weppos]

The problem is that the only way to be sure the referral works, is to execute a socket connection and rescue the error.

Honestly, I don't mind which kind of error occurs: it can be a connection failure, a socket error, a socket reset... etc. The result is the same: the second request fails but we already have a partial response.

I'm thinking about how to deal with it. If you ever read @avdi's book Exceptional Ruby (that I totally recommend), there are two concepts I think that we can apply here: tagged exceptions and nested exceptions.

The exception architecture in the Whois library is extremely powerful and was built with the idea that the end user should be able to rescue from any whois error to the most specific one taking advantage of exception classes. At the time being, in case of connection failure, a connection error is raised. There's no way to know if the connection failed at the first or second request and if we already have a response.

We may use the connection tagging to determine whether a specific exception embeds any response and nest into the exception itself the reference to the partial response, in case any exists. More or less like ActiveRecord does in case of validation error (it keeps a reference to the invalid object).

This is just brainstorming, but it summarizes more or less the idea I had in mind for such feature.

[rmabry]

Any progress on this? It would be a great addition to a great gem.