<div dir="ltr"><div dir="ltr">Hi Marcel,</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_-4549026248503032596m_4529078386620007980gmail-m_-676589593704447903__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)"><div><span style="font-size:10pt">At the moment, we have this hierarchy in Squeak's exception mechanism:</span><br></div><div><br></div><div>Exception < Error</div><div>Exception < Notification < Warning</div><div><span style="font-size:13.3333px">Exception < Halt</span></div><div><span style="font-size:13.3333px">Exception < UnhandledError < UnhandledWarning</span></div><div><span style="font-size:13.3333px"><br></span></div><div><span style="font-size:13.3333px">I think that something is conceptually wrong here. Notifications are supposed to be resumable and do nothing by default. Warnings, on the other hand, are resumable but interrupt the process by default. Like Halt does.</span></div></div></blockquote><div><br></div><div>I agree with your above statements except for something being conceptually wrong. It seems perfect to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_-4549026248503032596m_4529078386620007980gmail-m_-676589593704447903__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)"><div><span style="font-size:13.3333px"><br></span></div><div><span style="font-size:13.3333px">Not now, but in the future, I would like to change it to something like this:</span></div><div><span style="font-size:13.3333px"><br></span></div><div><div style="font-size:13.3333px">Exception < Error</div><div style="font-size:13.3333px">Exception < Notification</div><div style="font-size:13.3333px">Exception < ResumableInterrupt < Warning</div><div style="font-size:13.3333px"><span style="font-size:13.3333px">Exception < </span><span style="font-size:13.3333px">ResumableInterrupt</span><span style="font-size:13.3333px"> < Halt</span></div><div style="font-size:13.3333px"><span style="font-size:13.3333px">Exception < UnhandledError < UnhandledWarning</span></div></div><div><span style="font-size:13.3333px"><br></span></div><div><span style="font-size:13.3333px">Thoughts? </span></div></div></blockquote><div><br></div><div>Hmm. It took me a minute, but I think I see what you're _wanting_ to do. What I don't care for, however, is mixing this notion of "Resumable" with the fact that every Exception already understands #isResumable, and so would introduce a potential ambiguity or conflict between them. Perhaps I would like it better if it were just called "Interrupt", and leave the #isResumable nomenclature to be inherited from Exception>>#isResumable, however...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_-4549026248503032596m_4529078386620007980gmail-m_-676589593704447903__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)"><div><span style="font-size:13.3333px">Well, there are other notifications that interrupt the current process in a way: EnvironmentRequest, MCMergeResolutionRequest, ... Maybe my definition of "Notification" is wrong?</span></div></div></blockquote><div><br></div><div>... the "Interrupt" nature of the requests above is really a property _handling_, not requesting. For example, tit's only the #defaultAction of EnvironmentRequest that interrupts, but in a headless environment, bootstrap code would wrap it to avoid that:</div><div><br></div><div> [ ... ] </div><div> on: EnvironmentRequest</div><div> do: </div><div> [ : req | </div><div> "custom handling, NOT an interrupt" </div><div> req resume ]</div><div><br></div><div>Similarly, an example of the need for resumable Warning is exemplified by SmalltalkImage>>#run:. This is for headless servers, where one doesn't want an arbitrary Warning to stop the server, so the proper course of action is to log it and resume, always.</div><div></div><div></div><div><br></div><div>For Magma apps, I have a MagmaSessionRequest which is a Notification that is conveniently ignored unless one sets a Session. That way, one single application code base can be run equally either, in memory, or connected to a database, without any code changes or extra configuration.</div><div><br></div><div>"Requests" and Warnings absolutely need the flexibility of being Notifications, not only Interrupts. IMO, the choice to interrupt, or not, is made by the handling code.</div><div><br></div><div>Best,</div><div> Chris</div><div><br></div><div><br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_-4549026248503032596m_4529078386620007980gmail-m_-676589593704447903__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)"><div><span style="font-size:13.3333px"><br></span></div><div><span style="font-size:13.3333px">Best,</span></div><div><span style="font-size:13.3333px">Marcel</span></div><div><span style="font-size:13.3333px"><br></span></div><div><span style="font-size:13.3333px">P.S.: Why is CurrentReadOnlySourceFiles an Exception but CurrentEnvironment is a Notification? Sigh....</span></div></div><br>
</blockquote></div></div>