<div dir="ltr"><div dir="ltr">Hi Andres,<div><br></div><div>I'm really interested in this because I've always wondered if there was some reason I should use #return: instead of simply letting the last expression be the resultant value.  In general, I've not used #return: simply for brevity of code.</div><div><br></div><div>By "breakpoint", I assume you're referring to something other than changing the code and inserting a #halt.  Something like the old VisualAge breakpoints that replaces the CompiledMethod with one that halts somewhere on the line where the breakpoint was added, so that, as you said, you won't make the package dirty just for a quick debug.</div><div><br></div><div>Still, I was wondering if the benefit to using #return: is limited to the use of breakpoints, or if there are any other reasons I should use #return: in my handler.<br></div><div><br>Thanks,</div><div>  Chris</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 14, 2019 at 2:06 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">By the way, there is another exception handler block code pattern that <br>
obstructs debugging.  The problem is with exception handlers that do not <br>
tell the exception what to do, i.e.:<br>
<br>
        [:ex | nil]<br>
<br>
Suppose you have something like<br>
<br>
        on: SeveralKindsOfError do: [:ex | nil]<br>
<br>
and you need to sort out how it fails with only one of said exceptions. <br>
You can't put a breakpoint in [:ex | nil] because that code is heavily <br>
used by the system, and you can't breakpoint e.g. #return: for the <br>
exception you're interested in, e.g.:<br>
<br>
        InterestingException>>return: anObject<br>
<br>
                self halt.<br>
                ^super return: anObject<br>
<br>
because the message is not being sent in the first place.  Ok fine you <br>
modify the code while you're debugging, and now you need to remember <br>
that some package will look dirty for a while, and you also have to undo <br>
all those modifications before you post the actual intended changes. <br>
Anyone that has to debug that code will have to go through those <br>
motions, now and in the future.<br>
<br>
All that extra work goes away by writing<br>
<br>
        [:ex | ex return: nil]<br>
<br>
instead.<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></div>