Let's see...
One the one hand, that's some mighty clean code you have there.

On the other hand, you're adding five exception classes. It's not that
they cost money, but I don't like making stupid classes. I'm not
experienced using exceptions - what would you have them know? Maybe some
testing methods (isTimeout vs isDefinitelyAProblem) to do coarse
differentiation?

And, on the gripping hand, youve just pushed the handling code away
(admittedly, probably somewhere more appropriate). But what's it look
like there?

This example -
[
			self nextRequest startRetrieval
		] on: FTPConnectionException do: [ :ex | 
			Cursor normal show.
			self removeProcess: Processor activeProcess.
			self startDownload
		].

Doesn't explain how you'd differentiate between your five possible
exceptions and handle each right. Ideas?

On a tangent -
What about non-failure situations?
I'm an ExtractMethod refactoring, I've been sent by an unknown UI object
(or maybe a test class? might be non-interactive) to, well, extract a
method. Oi vey - I don't know what to call the new method. Who you gonna
call? how?

I'm thinking why I might not want to use an exception - maybe I don't
want to notify someone on my call stack. When is this likely to happen?

BTW, anyone know good pattern languages related to this stuff?

Hans-Martin Mosner <hm.mosner at cityweb.de> wrote:
> danielv at netvision.net.il wrote:
> > 
> I *feel* like exceptions would be the right thing to use here.
> First, the NetNameResolver should either return a resolved host address,
> or it should raise one of these exceptions: 'host not found', 'query
> timed out', or 'host has no address' (yes that's possible with DNS-based lookups).
> Second, either the #connectTo: or #waitForConnectionUntil: method should
> either return with the connected socket, or it should signal a
> 'connection rejected' or 'timed out' exception.
> Of course, other exceptions might exist for both of these cases...
> 
> Then the client might choose to catch and handle these exceptions, or it
> might just let its caller handle them. So the simplest version looks
> like this:
> 
> 	address := NetNameResolver addressForName: serverName timeout: 15.
> 	self connectTo: address port: 110.
> 	self waitForConnectionUntil: POPSocket standardDeadline.
> 	"After this, the socket is connected"
> 
> What do people think?
> 
> Cheers,
> Hans-Martin