[Cuis-dev] Exception handler blocks with non-local returns

[Phil B]

Andres,

On Tue, Oct 15, 2019 at 2:48 AM Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Phil,
>
> On 10/14/19 22:37, Phil B wrote:
> > - 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.
>
> IIRC, exceptions were a later invention.
>

That would make sense.  Blue Book etc. really seem most valuable re: the
specification of the VM.  I've always found their level of detail
describing image-level behavior to be vague / spotty.


>
> > - ANSI draft - Now we're getting somewhere...
> >
> > [snip]
>
> See section 5.5.2.1, which (if I'm reading it right) says that if a
> handler block does not tell the exception what to do, the behavior is
> equivalent to doing ex return: (the value of the block).
>

Ah, yes... that would be my initial interpretation as well.  (I had managed
to skip over that section as I've been staring at too much text tonight.
I'll need to re-read when I'm fresh)


>
> However, the text prefixes that specification by stating "if the block
> answers normally, as if returning from the message #value:".  Ok, so now
> we have an interpretation problem.
>
> Does "answer normally" include non-local return?
>
> 1.  Suppose the answer is 'yes'.  Then what does it mean to do
>
>         ex return: anObject
>
> in order to return to a block that is no longer in the stack, because
> presumably the non-local return unwound the receiver of on:do: as well?
> This interpretation does not make sense.
>
> 2.  So suppose the answer is 'no'.  Then what happens when the handler
> block has a non-local return?  I do not immediately see what the spec
> says should happen, especially wrt the exception environment --- is that
> even supposed to be reset?  I'd like to believe so, because otherwise
> consider the horrors of a non-local return skipping past exception
> handlers without resetting the exception environment to the closest
> still active handler.
>
> Maybe I missed the text that says what happens?
>

I think I'm with you on this.  I guess it depends on how one interprets
Section 3.4.5.1 as it relates to exceptions? (i.e. is the home activation
of the block considered terminated while in the exception handler?  The
fact that it may not be from a VM/image implementation standpoint doesn't
necessarily mean that it shouldn't be logically... we are in an exceptional
state after all and have redirected control flow for a reason.  Or should
we be thinking of exceptions really as just dressed up gosubs?  I think at
this point I'm just restating your original complaint on this...)


> > Taken together, I'd interpret that as any return value from the handler
> > block is a gray area and implementer's choice.
>
> IIRC, there's non-zero truth in this.  But let's make sure, I'll do some
> more digging tomorrow.
>
> > 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.
> >
> > Unless someone can find something else to make be feel better, I'm in
> > full agreement that we do have a problem.
>
> Repeatedly running into this kind of situation is one of the things that
> often makes me wish programs were very explicit about what they want to
> happen.  Because then, if (say) we wanted to change how exceptions work,
> then we can reimplement the messages the application sends so they
> provide the expected behavior in the new world, and everyone's happy.
>

Exactly.  It's not that I care so much which way things (in this case,
Exception) work, only that it is consistent and documented so I can depend
on whatever behavior is there not to change underneath my code.


>
> But if programs do not explicitly say what they mean, now we're in the
> business of guessing.  There's no way to win that, so the steady state
> becomes 'nothing changes anymore'.  Obviously that's unacceptable.
>

Agreed.  That's why I'm looking for anything that would either point us
toward 'yes, this is valid/allowed' or 'no, it isn't'.  If nothing exists,
then sure it's fair game to make a call one way or the other.  But to make
that call if something exists that contradicts the decision may, depending
on the source, be unwise.


>
> Andres.
>
>
Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191015/5b3929eb/attachment.htm>