On Thursday 26 June 2003 07:44 am, goran.krampe at bluefish.se wrote:
> Ned Konz <ned at bike-nomad.com> wrote:
> > On Thursday 26 June 2003 12:53 am, goran.krampe at bluefish.se wrote:
> > > Ah, right. Just tested it. This is in fact due to the network
> > > rewrite - the SM code isn't prepared for an Error. :-)
> >
> > Yeah. So we need to rip out the raising of the error and instead
> > do one of:
> > * return nil as before
> > * let the error propagate (which means that you will get the "try
> > again/give up" confirmation if we don't change the handling)
>
> Eh, I am not following. Why shouldn't we just adapt SM and add some
> error handling?

I think we should do both.

The existing senders of the lookup message expect to get a nil back on 
failure.

Previously, on a timeout or failure, there was a prompt given. Michael 
moved this into the default action on the name resolver Error.

But adding the raising of the Error changed the behavior of existing 
clients. Instead of getting a prompt and eventually getting nils on 
failure, now an Error is raised that wasn't before.

So the NameLookupError doesn't propagate, and SM couldn't catch it.

Just remove the IfError: clause from addressForName:timeout and 
nameForAddress:timeout: and things will be fine. SM can check for the 
NameLookupError, and other clients will continue to behave as before.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE