[Pharo-project] Announcement real problems - please read and comment.

Henrik Johansen henrik.s.johansen at veloxit.no
Mon Apr 4 18:22:05 CEST 2011

On Apr 4, 2011, at 5:42 38PM, Stéphane Ducasse wrote:

> Ok guys so I want a solution :).
> So how can we improve Announcement to cover different cases?
> Stef
Both solutions lead to remaining subscribers being notified when an error occurs.
So which is decided upon, depends on which of their respective benefits are valued more.
For that, it'd be nice if more than 2 people chimed in on. :)

Short summary (not guaranteed to be 100% objective)

Curtailing -> 
- Your image may crash in some cases, more specifically if you:
1) have errors in subscribers to announcements made in system-critical processes, as they will be suspended while debugging.
2) deliver announcements in a separate thread from where they're announced, and the announcing thread does so regularily.
+ Easy to debug. Entire call-chain available, no modification to state caused by subsequent subscribers. Restart should always lead in bug being reproduceable.

The remove-from-subscriptions part of Error-handling and ifCurtailed could be combined as well, in which case #2 no longer applies.

Error handling -> 
- Hard/impossible to debug because:
1) If your error was in ordering, debugger will step through flawlessly if restarted.
2) You start at the context of the subscriptions action, no idea where it came from.
+ More robust, none of the cases mentioned in Curtailing will crash your image. 

With the different pros/cons mentioned above in mind, here are .cs with example implementations for what  both Igor / I would like. (minus remove-from-subscriptions for ifCurtailed: )

-------------- next part --------------
A non-text attachment was scrubbed...
Name: AnnouncementErrorHandling.zip
Type: application/zip
Size: 1702 bytes
Desc: not available
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110404/e9920972/attachment.zip>

More information about the Pharo-project mailing list