<div dir="ltr"><div dir="ltr">Andres,<div><br></div><div>Still working on this part:</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 13, 2019 at 10:51 PM 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">Do we even agree this is a problem?<br></blockquote><div><br></div><div>So I did some research:</div><div><br></div><div>- Blue Book - Useless... the only thing remotely mentioning exceptions had nothing to do with them.  I don't  see #on:do: referenced anywhere.  Wondering if Exception as we know it even existed back then?  I see things like SyntaxError hanging directly off of Object.</div><div><br></div><div>- Orange Book - Section 4 (starting on p. 351) is all about error handling.  However, it mostly appears to be dealing with using the tools and doesn't define the mechanism.  No help.</div><div><br></div><div>- ANSI draft - Now we're getting somewhere...</div><div><br></div><div>On p.84 the define #on:do: an mention that 'The result of evaluating the receiver is returned.'  It says nothing about the result of evaluating the exception block.  Something interesting is that on p.84 when talking about #ensure: and #ifCurtailed: they go to the effort of explicitly stating 'the value returned from the evaluation of terminationBlock is discarded' but for whatever reason didn't say anything (the same or different) for #on:do:.</div><div><br></div><div>On p.92 they define the signaledException protocol which includes #return, #return: etc. and states 'These message are used to explicitly control how execution will continue when it leaves the handler block.'</div><div><br></div><div>Taken together, I'd interpret that as any return value from the handler block is a gray area and implementer's choice.  So as I believe you've stated, the only way to ensure a specific return a value is to send #return (for nil) or #return: (for any other value.)  I find that more than a bit scary since it means that the behavior before the most recent changes was valid.  And so was the behavior after the most recent changes.</div><div><br></div><div>Unless someone can find something else to make be feel better, I'm in full agreement that we do have a problem.</div><div><br></div><div></div></div></div>