You could also try something similar to the way the UI process deals 
with opening the debugger...but IIRC, that seems like a less general 
solution.  But, something along the lines of isolating the halt in it's 
own process would be good.  In your example, how would you deal with two 
halts in two or more of the event dependents?

Btw, what are the issues with doing the event notifications 
asyncronously in their own processes?

- Stephen

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
>
>
>  
>


-- 
- Stephen
_________
Do you need:
  Web/Domain/Application Hosting?
  Mailing List Services?
  IMAP/POP3/Web Email Accounts?
  Instant Messaging Accounts hosted on your domain?

Email me for information.