<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">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><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>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>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><br></div><div>Hernan. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> but the problem I'm pointing at <br>
is left unaddressed. The issue here is that handler blocks end up <br>
depending on private implementation details, which means changing <br>
exception handling is more difficult.<br>
<br>
> ----<br>
> b) that kind of behavior is what the messages #return, #resume, #pass,<br>
> #outer, etc are there for,<br>
> ----<br>
> Well , not really, non of them have the same semantics of non local return.<br>
<br>
Right, I meant that's what *messages* are there for, such as #return, <br>
#resume, and so on. Perhaps exceptions should be told to do a non-local <br>
return with a message, too.<br>
<br>
> I do not see a problem in debugging something line [] on: Error do: [ ^5 <br>
> ]. If I want to do it I would do this: [] on: Error do: [ ^5 halt ]<br>
<br>
I was thinking of the long term consequences of writing code a certain <br>
way, and my experiences debugging exception handling itself (where, <br>
perhaps, there are places that cannot tolerate a non-local return). <br>
Code that is explicit about what is intended makes such work much easier <br>
(some people called that code 'intention revealing').<br>
<br>
In contrast, using non-local returns creates dependencies on the <br>
particular flavor of exception handling you have. Something similar <br>
happens with not telling the exception what you want done.<br>
<br>
> Regarding confusing [] on: Error do: [ ^5 ] with [] on: Error do: [ :ex <br>
> | ex return: 5 ], that could happen with non local returns everywhere, <br>
> that is a problem of not knowing what non local returns really means, <br>
> not a problem on how to use exception handling...<br>
<br>
I think we just have different perspectives. When code gets really hard <br>
to understand, the work is often organized so that O(1) VM engineers <br>
debug O(n) problems. That does not scale.<br>
<br>
Andres.<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal"><span style="font-weight:bold">Hernán Wilkinson</span><br>Agile Software Development, Teaching & Coaching</span></font></span></span></span></strong></span></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">Phone: +54-011</span></font></span></span></span></strong></span><font face="tahoma, sans-serif" size="2">-4893-2057</font></div><div><strong style="font-family:tahoma,sans-serif;font-size:xx-small"><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Twitter: @HernanWilkinson</span></font></span></span></strong></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">site: <a href="http://www.10pines.com/" style="color:rgb(17,65,112)" target="_blank">http://www.10Pines.com</a></span></font></span></span></span></strong></span></div><div><font face="tahoma, sans-serif"><span style="border-collapse:collapse">Address: Alem 896</span></font>, Floor 6, Buenos Aires, Argentina</div></div></div></div></div></div></div></div></div></div></div></div></div>