Updates:
Cc:
[hidden email]
Comment #2 on issue 4528 by
[hidden email]: Exception on:fork:
enhancement
http://code.google.com/p/pharo/issues/detail?id=4528in 1.3 we introduced on:fork: to ensure that for example a system
announcement is processed even if a user announcement would break for the
same registry.
I saw that, but didn't understand the implications.
The idea is that on Error the stack is copied and forked and the current
process is resumed.
The problem is that the code does not only catches Error, but
Exception. This means it will also capture notifications, or any other
exception that your code might be handling.
Now with DynamicVariable (and probably Notification)
the stack is cut and the resume of the notification or dynamic variable
gets nuts because it does not find the information it needs.
I think this is a serious problem in the new announcer framework.
Announcing something should not affect the existing exception handing.
I believe the problem could be fixed (for most users) if announcements
would catch UnhandledError only, this exception is raised to open the
debugger.
We believe that on: fork: will really improve the stability of the system
(ui process, announcement). We want to be able to debug UI process without
having to rinstall the current process
and all the current magic. I do not want to see the new package system on
its knees just because somebody registered a broken announcement on a
systemEvent (it already happened before on:fork:).
Yes, but you should not interfere with intentionally raised exceptions
(and this is not only for notifications). The current announcement
implementation breaks many users and many legitimate use-cases.
Lukas
_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Locked
