<div dir="ltr"><div dir="ltr">Hernan,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 15, 2019 at 7:13 AM Hernan Wilkinson via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 15, 2019 at 1:00 AM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
> Andres, when you say:<br>
> ---<br>
> a) effectively, nobody is looking at how the exception handling<br>
> mechanism is implemented, so doing non-local return like that curtails<br>
> the private implementation of exception handling,<br>
> ---<br>
> The solution is to make the exception handling implementation aware of <br>
> this situation. As it is right now, it works correctly<br>
<br>
Hang on: you're providing a 'solution',</blockquote><div><br></div><div>the thing is that I don't see a problem :-)</div></div></div></blockquote><div><br></div><div>Unfortunately, thanks to Andres, I now see it and it's hard to un-see.  And you say that but then write this...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>BTW, what I really see as cumbersome is having to tell the exception #return: or #resume: or #retry. </div><div>Conceptually that does not make sense, is not the exception that returns, resumes neither retries, it is the block or collaboration that generated the exception.</div></div></div></blockquote><div><br></div><div>Unless the intent of those methods is to transfer control to the exception.  Assuming that is the case, was the intent that this transfer of control be optional or mandatory?   It's entirely possible that this whole issue boils down to 'the problem with blocks.'  So the question we have to answer is: is it a feature, a bug with a feature, or a feature with a bug?</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 dir="ltr"><div class="gmail_quote"><div>I think those messages should be sent to another object... but from the semantics point of view, it does not make sense the receiver to be the exception.</div></div></div></blockquote><div><br></div><div>... unless the intent was to transfer control.</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 dir="ltr"><div class="gmail_quote"><div>Or maybe the messages should be change to #returnFromBlockWith:, #resumeCollaborationWith: and #retryBlock.</div><div><br></div><div>On the other hand, I just try this issue in other languages. In Ruby, another language with non local returns, it works as it currently does in Smalltalk. In Java, there is no non local return, but you can put a return in an exc. handler and behaves correctly returning from the method that contains the exc. handler.</div></div></div></blockquote><div><br></div><div>Keep in mind that most other languages blow up and die when you raise an exception ;-)  And there are also languages that treat exceptions as an explicit transfer of control where things like non-local returns would not be allowed, if they even exist in the language.   Of course there's also the age-old debate of why do exceptions exist and when should they be used or not used.</div><div><br></div><div>But the issue isn't what do other languages do, it is more what do we want Cuis to do?  Is it important that Cuis be/stay compatible with other Smalltalk implementations on this front?  This has  obvious short term impact to anyone's exception handling code both in terms of porting and writing.   But it also has longer term implications for anyone making changes that assume/depend on having control of execution as it relates to enhancing the debugger, exceptions themselves or some other related feature/capability.<br></div></div></div>