>>> >>> >> 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??) >> > Ah, yes. We have ifCurtailed: there as well. So, putting UnhandledError > in delivery sounds like good way to resolve the conflict of interests.
So I let you propose a fix and I will integrate it because I like to do idiot actions :) >> 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? >> > indeed.
