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

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Apr 4 22:27:01 CEST 2011


> 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. :)

:)
Me too
Thanks a lot for the analysis and pros and cons!
I have the impression but I would really like to hear other voices on it that the ease of debugging is a big plus for me.
But robustness is important too.

> 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: )
> 
> Cheers,
> Henry
> <AnnouncementErrorHandling.zip>




More information about the Pharo-project mailing list