Exception handling question

Roel Wuyts wuyts at iam.unibe.ch
Wed Aug 6 07:31:07 UTC 2003


Wait, wait, hold your horses.
I do not want to just 'eat' your halts. Then how am I going to 
implement this thing?! :-) A form of what Andreas describes below (and 
for exactly the same reason) is already in the notification mechanism 
for a couple of weeks (I am working on it, it is not fullproof nor 
finished yet). But it depends on me being able to catch your halt 
first. That was the only point I was trying to make.


On Tuesday, Aug 5, 2003, at 18:09 Europe/Zurich, Andreas Raab wrote:

>> And, I'd argue that when I say #halt, I mean #halt, and don't
>> want your handler to trap it.  I could equally make the case
>> in your example that halting the process without you trapping
>> it is exactly what I want to happen in order to debug your
>> exception handlers.
>
> Or in order to debug some obscure case of event notification failure. I
> agree that #halt should halt. One thing that the notification mechanism
> could do here is to provide some support for any of the "other 
> clients" so
> that (successful or not) debugging one client doesn't totally screw 
> up. In
> short, all of the clients must, under all situations being given the 
> chance
> to handle the notification. This can be done by simply first trapping 
> halt
> and then proceeding it. Somewhat along the lines of:
>
> notifyAll: clients about: anEvent
>
>   clients keysAndValuesDo:[:index :aClient|
> 	[
> 		[self notify: aClient about: anEvent]
> 			on: Error do:[:ex| "handle errors"].
>
> 	] on: Halt do:[:aHalt|
> 		"Someone's trying to debug me.
> 		Fine, but before we allow this process any
> 		of the others."
> 		self notifyAll: (clients copyFrom: index+1 to: aCollection
> size) about: anEvent.
> 		aHalt pass. "now fall into debugger"
> 	].
>   ].
>
> The above method may have some problems with multiple halts occuring 
> and can
> be somewhat obscure if there is an ordering problem (side effects which
> aren't seen due to the out-of-order processing of the later clients) 
> but I
> don't think there's much that can be done otherwise.
> 				
> Cheers,
>   - Andreas
>
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org



More information about the Squeak-dev mailing list