>> Announcing something should not affect the existing exception handing. > > Yes but errors in handler should not break other announcements.
I agree, but then it should be possible to intentionally abort the announcement handling. This behavior is used in OB to warn the user about an unsaved method and potentially abort the announcement processing. But then again, this will never work with the new Pharo announcements, because the handlers are stored in an IdentitySet and are executed in random order anyway. >> Yes, but you should not interfere with intentionally raised exceptions >> (and this is not only for notifications). The current announcement >> implementation breaks many users and many legitimate use-cases. > > do you have some examples so that we can understand on real use cases? Any application that handles exceptions itself and that uses announcements likely breaks with then changes in Pharo 1.3: - Any UI tool that does interactions and queries through exception processing: OB, users of UIManager, MenuMorph, ... - Any persistency layer that ties transactions to the stack (or process): Magma, OmniBase, Goods, ROE, ... - Any web framework (or other non-morphic UI tool) that has its own exception handling: Seaside, Kom, GTK, Cocoa, ... > Again there are parts of the system that we want really robust and > breaking the propagation of announcement because one is broken > is not really good. Now this is not really a big deal for me, OB works perfectly in Pharo 1.3 with its own "old" announcement implementation. It is just that everybody should be aware of the problem and have its own "simple" announcements when using any of the frameworks above. Lukas -- Lukas Renggli www.lukas-renggli.ch
