Hi All, Hi Chris,
something in the changes to ProcessInitiationException done in ToolBuilder-Kernel-cmm.48/49/52 breaks the VMMaker. i.e. the following prints nil 5 times to the Transcript instead of printing #caught 5 times.
['Progressing' displayProgressFrom: 1 to: 5 during: [:bar| 1 to: 5 do: [:i| Transcript cr; print: (Notification new tag: #getVMMaker; signal); flush. bar value: i]]] on: Notification do:[:ex| ex tag == #getVMMaker ifTrue: [ex resume: #caught] ifFalse: [ex pass]]
Any help in fixing this appreciated!
Interestingly in the following count is 1
| count | count := 0. ['Progressing' displayProgressFrom: 1 to: 5 during: [:bar| 1 to: 5 do: [:i| Transcript cr; print: (Notification new tag: #getVMMaker; signal); flush. bar value: i]]] on: Notification do:[:ex| count := count + 1. ex tag == #getVMMaker ifTrue: [ex resume: #caught] ifFalse: [ex pass]]. count 1
Hi,
Executing your example, these things happen:
- String >> displayProgressFrom:to:during: throws a ProgressInitiationException, which is a Notification - Your handler block passes that notification - It executes its defaultAction, which includes executing the during block
So the problem is that execution of the during block happens outside your Notification handling.
Btw the comment of ToolBuilder-Kernel-cmm.52 says: "Fix ability to safely catch Notification so that, if #displayProgressAt:from:to:during: is sent, will actually execute the during block."
It would be help to see, what situation was fixed by this change. It's still not entirely safe to catch Notifications around display progress calls. E.g. if you send #resume: to the Notifications you catch, the during block won't run.
A quick fix, at least for the example, is to move the Notification handling inside the during block. Another is to change the superclass of ProgressInitiationException from Notification to Exception.
Cheers, Balázs
Another is to change the superclass of ProgressInitiationException from Notification to Exception.
Actually I don't understand why exactly this works. It could be something like that you can't activate an exception handling block more than once, and now we activating it only once, but in the original setting it was activated by the ProgressInitiationException, and it won't trigger for the subsequently signalled Notifications?
Balázs
I poked around a bit more, and found a method to handle these kind of situations: #rearmHandlerDuring: You could rewrite the exception handling block to something like this:
[ :ex | ex tag == #getVMMaker ifTrue: [ ex resume: #caught ] ifFalse: [ ex rearmHandlerDuring: [ ex pass ] ] ]
and get five #cought on the Transcript
On Sat, Jun 23, 2012 at 10:13 AM, Balázs Kósi kosi.balazs@ezomer.hu wrote:
I poked around a bit more, and found a method to handle these kind of situations: #rearmHandlerDuring: You could rewrite the exception handling block to something like this:
[ :ex | ex tag == #getVMMaker ifTrue: [ ex resume: #caught ] ifFalse: [ ex rearmHandlerDuring: [ ex pass ] ] ]
and get five #cought on the Transcript
Thanks, Balázs!!
On Sat, Jun 23, 2012 at 10:13 AM, Balázs Kósi kosi.balazs@ezomer.hu wrote:
I poked around a bit more, and found a method to handle these kind of situations: #rearmHandlerDuring: You could rewrite the exception handling block to something like this:
[ :ex | ex tag == #getVMMaker ifTrue: [ ex resume: #caught ] ifFalse: [ ex rearmHandlerDuring: [ ex pass ] ] ]
and get five #cought on the Transcript
So is this a hack that points to a bug in the exception handling system or what? I don't have time to think about this carefully right now, but it looks like this is covering up a serious bug in the exception system. Thoughts?
vm-dev@lists.squeakfoundation.org