Hi Bernat,
Until Pharo sorts our how they are going to fix it, we fixed it by overriding two methods.
AnnouncementSubscription>>deliver: anAnnouncement
" Overridden code has a fork in here. Not good."
^ (self handles: anAnnouncement class)
ifTrue: [ action cull: anAnnouncement cull: announcer ]
SubscriptionRegistry>>deliver: anAnnouncement to: subs
subs do: [ :each | each deliver: anAnnouncement ]
On Mon, Jul 18, 2011 at 11:13 AM, Bernat Romagosa
<tibabenfortlapalanca@gmail.com> wrote:
Hi,
I am having the exact same problem with an Iliad app, which stopped working in 1.3 because it loses the context when catching an announcement.�I'd really love to know the solution to this, in the Iliad list we didn't manage to fix it.
Cheers,
2011/7/18 Norbert Hartl
<norbert@hartl.name>
Am 17.07.2011 um 22:06 schrieb St�phane Ducasse:
>> It is just that everybody should be aware of the problem and have its own "simple"
>> announcements when using any of the frameworks above.
>
> you know that this is not the good solution. So probably it was a bad idea to catch
> everything and probably UnhandledError is a better choice.
> Now again without feedback we will just progress but much slower.
Why is the usage of on:fork: not an option of the Announcer? We don't have one single Announcer in the system so I don't see the need why they should behave all the same. Over time I think there will be multiple announcers in the system that have different impact in case something goes wrong. For the core announcers on:fork: is probably a good idea to preserve consistency in the system.
For the rest it may be better to preserve stack to be able to debug and to reduce side effects. I think on:fork is targetted to an edge case so it should not be the default.
my 2 cents,
Norbert
--
Bernat Romagosa.
--
Danie Roux *shuffle* Adore Unix - http://danieroux.com
Email / Google Talk / Jabber - danie@danieroux.com