We will think hard and see what is a reasonable solution. What we want is the garantee that announcements are processed, that UI continue to work even if a piece of code break part of it, same for event handling.
>> in 1.3 we introduced on:fork: to ensure that for example a system >> announcement is processed even if a user announcement would break for the >> same registry. > > I saw that, but didn't understand the implications. > >> The idea is that on Error the stack is copied and forked and the current >> process is resumed. > > The problem is that the code does not only catches Error, but > Exception. This means it will also capture notifications, or any other > exception that your code might be handling. Indeed this is why we probably need to way to let the programmer define the exception that he does not want to be caught. >> Now with DynamicVariable (and probably Notification) >> the stack is cut and the resume of the notification or dynamic variable gets >> nuts because it does not find the information it needs. > > I think this is a serious problem in the new announcer framework. From a certain perspective it also work better than the previous one, so this is not black and white. > Announcing something should not affect the existing exception handing. Yes but errors in handler should not break other announcements. > I believe the problem could be fixed (for most users) if announcements > would catch UnhandledError only, this exception is raised to open the > debugger. May be, we will think about that. >> We believe that on: fork: will really improve the stability of the system >> (ui process, announcement). We want to be able to debug UI process without >> having to rinstall the current process >> and all the current magic. I do not want to see the new package system on >> its knees just because somebody registered a broken announcement on a >> systemEvent (it already happened before on:fork:). > > 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? because we were checking ours and it worked for us. 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. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >
