I think this is especially confusing since the comment says that the primitive always fails, and then the expectation is that the Smalltalk code that follows is executed instead. But that code does not do what the method actually does

On Mon, Aug 31, 2020 at 4:51 PM Florin Mateoc <florin.mateoc@gmail.com> wrote:
Hi Eliot,

Sorry about top-posting previously. Stupid Gmail!

Eliot Miranda via squeak.org 

4:40 PM (4 minutes ago)


to Open

On Mon, Aug 31, 2020 at 4:40 PM Eliot Miranda <eliot.miranda@gmail.com> wrote:
 
Hi Florin,

On Mon, Aug 31, 2020 at 1:35 PM Florin Mateoc <florin.mateoc@gmail.com> wrote:
 
Hi Eliot,

Thank you for your reply and for the extra details about #instVarAt:.
To answer your question, I would have expected the primitive to fail for non-pointers objects, as I associate in my mind instvars with named instvars, but I am not invested in this (mis)association, so thank you for correcting it.

But regarding #ifCurtailed, I know that primitives198 1nd 199 are not "real", I was referring to something else. The primitive failure code in the method #ifCurtailed never touches the argument, regardless of the path taken. I think that is incorrect, even if only for documentation purposes.

I don't understand.  I see no error code.  We're talking about this method right?

BlockClosure>>ifCurtailed: aBlock
"Evaluate the receiver with an abnormal termination action.
Evaluate aBlock only if execution is unwound during execution
of the receiver.  If execution of the receiver finishes normally do
not evaluate aBlock.  N.B.  This method is *not* implemented as a
primitive.  Primitive 198 always fails.  The VM uses prim 198 in a
context's method as the mark for an ensure:/ifCurtailed: activation."
| complete result |
<primitive: 198>
result := self valueNoContextSwitch.
complete := true.
^result
 



I did not mention an error code, I was talking about the "primitive failure code", referring to the Smalltalk code that gets invoked when the primitive fails (the three rows after the pragma).
This Smalltalk code does not touch the method's argument (aBlock), so it looks as if aBlock is never evaluated

Florin