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.