On Sun, 02 Jan 2005 11:00:35 +0000, Christophe Rhodes <csr21@...> wro=
> From the horse's mouth (otherwise known as "I asked Dan on IRC"): I
> think there is some confusion lurking in the code which may or may not
> be an indication of residual confusion in what name-service-errors
> are. On the other hand, you're the second person at least to raise
> this, so if there's confusion it's quite likely to be in sbcl's side.
Heh. Actually, it was the name inconsistency threw me, more than
whether or not this situation merits "errors" or "conditions." I tend
to expect conditions with "error" in the name to subclass error, and
those with "condition" not to subclass error.
> There is a try-again-error which is indicative of a temporary failure,
> as I understand. I don't know whether this should be an error or not;
> I think it probably should; Dan seems to think that he was a lot less
> clear on the condition system (and the distinction between the SIGNAL
> and ERROR functions) when he wrote net-telent-sockets.
I don't think the estimated duration of the problem is enough to
determine the condition class, but rather if there's a defined way to
handle it. If the signaller has a defined retry strategy, then it
should probably signal a condition, but not hit the debugger. In our
case, though, all we're being told is that the error is temporary and
amenable to retries, but we lack a handler definition (3 retries? 15?
Infinite? In linear time? Exponential? Should we suspend
processing until then? Spawn a thread? Pass back a retry-thunk?=20
In a protocol with a defined retry strategy and a defined interaction
with other tasks (running in it's own thread, say), then we could just
signal the condition and merrily retry every so often, perhaps. But
sb-bsd-sockets doesn't define either of these things, so signalling an
error seems reasonable to me.
> So, unless I hear otherwise I will probably make the change to the
> name-service-error superclass; but it's not something that I
> personally feel confident about, because I don't know much about
> networking protocols or about the sb-bsd-sockets code.
Happy new year to you all!