Stéphane Ducasse wrote: > > We will think hard and see what is a reasonable solution. > What we want is the garantee that announcements are processed, that UI > continue to work even if a piece of code break part of it, same for event > handling. > > Lukas suggestion of changing it to fork on UnhandledErrors is a perfectly reasonable solution.
In case handlers outside the delivery mechanism itself don't resume, well, the ifCurtailed: block of deliver:to: takes care of delivery to the remaining subscriptions. :) (except there's a bug when asking for after: of last element... ifAbsent: block used _both_ when element not found, AND when there are none after it??) You can still break it though, by using a handler which enters an infinite loop/sleep forever, etc... I agree with Phillipe: "The only way to fix broken code is to fix broken code, not by adding additional hacks.". Robustness is desirable, but only to a certain extent. (IE guard against unforeseen errors, not those handled incorrectly) As for Lukas' concerns not addressed by switching to UnhandledError: In my experience when using announcements in VW, relying on delivery order of announcements isasking for trouble later on... The code paths get hard to follow, maintainability becomes a nightmare as adding new subscribers/modifying old ones might introduce subtle bugs, etc. For the use case you described in OB, why not split it into two announcements instead, the first one vetoable in the sense Vassily wrote about in the blog, and the second announced only if first not vetoed? Cheers, Henry -- View this message in context: http://forum.world.st/Problem-with-announcements-in-Seaside-when-using-Pharo-1-3-tp3673669p3675019.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
