I've been looking at and modifying the RefactoringBrowser and the Squeak
Parser, and I've been puzzled by something.

Look at this bit of code -

	address _ NetNameResolver addressForName: serverName timeout: 15.
	address = nil ifTrue: [
->		self error: 'Could not find host address'].

	"connect the socket"
	self connectTo: address port: 110.
	(self waitForConnectionUntil: POPSocket standardDeadline) ifFalse: [
		self close.
->		self reportToObservers: 'failed to connect to server'.
->		^false ].

Marked by arrows are three different mechanism used by a functional
object (a low level object) to request that it's client handle a
situation.

error: raises an exception to be handled somewhere higher in the call
hierarchy.
reportToObservers: basically know it has observers (the pattern
abstracts away who they are)
^false tells it's immidiate caller that the results of an operation that
is finished is false.

I've noticed that many doer classes (like the Parser) use some mixture
of these techniques. The Parser specifically, is used by quite a few
different types of clients, uses both of the first techniques. Note that
neither method is used exclusively for terminating a process.
(see Parser>>notify:at:
and also in Parser>>parse: sourceStream class: class noPattern:
noPattern context: ctxt notifying: req ifFail: aBlock
see "RequestAlternateSyntaxSetting signal and: [(sourceStream isKindOf:
FileStream) not]")

The Refactoring classes use all those and more, also. 

It's not clear to me why each is chosen in each case... it simply looks
arbitrary and messy.

So - 
What are the Pros and Cons for exceptions and other callback mechanisms?

Daniel