> 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. > 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. Announcing something should not affect the existing exception handing. I believe the problem could be fixed (for most users) if announcements would catch UnhandledError only, this exception is raised to open the debugger. > 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. Lukas -- Lukas Renggli www.lukas-renggli.ch
