On 17 July 2011 22:06, Stéphane Ducasse <[email protected]> wrote: > > 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. >
No, i don't think its bad idea. A different subscriptions may not know about each other (otherwise, why you subscribing twice for same announcement, if you can do it only once?). And in such setup the announcement framework is there to provide a guarantees that announcement will be delivered to subscriber even if one/some of them fail to handle it properly and throw an exception. >From announcer point of view a general expectation that different subscriptions may not know about each other. (i think this is not questionable statement?) So, if you follow this expectation, it makes no sense to reason which subscriber should receive an announcement first and which one second. Because announcer simply broadcasting announcement to all interesting parties (subscriptions), and there is no need to maintain the order, but instead we should maintain the guarantee that announcement will be delivered to all subscriptions. If you look at this from given angle, you will see that instead, enforcing a specific order is bad idea. > >>>> 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. > But where the guarantees that other Exceptions resuming normally and not breaking a normal processing flow? And where the guarantees that all exception handlers sending #resume after done handling them? The problem that here we have conflict of interests: - we want that announcements to be always delivered to all subscribers - but one of the subscribers while handling anouncement may break the processing using Exception(s) and prevent others from handling an announcement. So, to peacefully resolve the conflict, we added #alwaysResuming flag to exception protocol. It should mean that: - an exception is _always_ resuming a normal processing flow after being handled. Note that it is more responsibility of implementors of exception handlers to maintain that property, rather than exception itself. In this case, only if you guarantee that exception won't break a normal processing flow, then on:fork: doesn't forking and not splitting the stack. Otherwise it have to fork (with all consequences) to ensure announcement delivery. Does that sounds reasonable? Also, let me remind you that exceptions are there is to handle an exceptional conditions in processing flow i.e. when something goes wrong and not as expected. So, it is perfectly reasonable to use #on:fork: to prevent announcement handling process from escaping the normal processing flow. Because normally , there should be no exceptions. For instance, in Seaside (if i remember correctly) it creates a separate process for handling request. And so, for dynamic variables you can use a process-specific storage , provided by Process>>environmentAt: and environmentAt:put:, rather than using exceptions to access dynamic variable values. Like that, you don't need to use exceptions and moreover it will work much faster, because unwinding stack each time you accessing the state is costly! > Stef -- Best regards, Igor Stasenko AKA sig.
