On Jul 17, 2011, at 9:57 PM, Lukas Renggli wrote: >>> 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.
ok but if you do not say it how can we improve? So now we learned that using an identitySet was a bad idea. You see if you would have given information when you got the problems we would have probably fixed everything. >>> 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, ... OB I know but this is notification, no? UIManager? really for the progressNotification? MenuMorph is using Exception? > - 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. this is not the point. We want to make the infrastructure really good. So we will fix that but for that we need inputs. If everybody "fixes" his stuff in his corner then we should better stop pharo. > It is just that everybody should be aware of the problem and have its own > "simple" > announcements when using any of the frameworks above. you know that this is not the good solution. So probably it was a bad idea to catch everything and probably UnhandledError is a better choice. Now again without feedback we will just progress but much slower. Stef > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >
