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
|