For handlerActive, it's tricky, look at (tempAt: 3) below:

ContextPart>>canHandleSignal: exception
	"Sent to handler (on:do:) contexts only.  If my exception class
(first arg) handles exception then return true, otherwise forward this
message to the next handler context.  If none left, return false (see
nil>>canHandleSignal:)"

	^ (((self tempAt: 1) handles: exception) and: [self tempAt: 3])
		or: [self nextHandlerContext canHandleSignal: exception].

For primitive 199, it must be tricky too.
But you can't implement in say Object>>testPrim199
    <primitive: 199>
    self error: 'debug me'

 because it breaks the error handling :)

Nicolas

2011/4/14 Frank Shearar <frank.shearar at angband.za.org>:
> I'm playing around with Danvy and Filinski's shift/reset operators, which
> allow a nice (lexically scoped) syntax for capturing partial continuations.
>
> In particular, reset marks the stack in some way, and a later shift reifies
> the call stack between itself and reset as a function.
>
> To that end, I'm delving into the guts of how exceptions work. I've a few
> questions:
>
> First, I know that VMMaker (especially Interpreter
> class>>initializeBytecodeTable) lists all the known numbered primitives. In
> particular, BlockClosure>>on:do: uses <primitive: 199>.
>
> on: exception do: handlerAction
>        "Evaluate the receiver in the scope of an exception handler."
>
>        | handlerActive |
>        <primitive: 199>  "just a marker, fail and execute the following"
>        handlerActive := true.
>        ^ self value
>
> and
>
> bytecodePrimClass
>        | rcvr |
>        rcvr := self internalStackTop.
>        self internalPop: 1 thenPush: (self fetchClassOf: rcvr).
>        self fetchNextBytecode.
>
> is the implementation of that bytecode.
>
> But what's this really doing? Or, rather, how is what it's doing connected
> with marking a context so as to find an exception handler?
>
> If it's purely a marker, could one use another primitive? (Other than
> "that's how we do it, and Things Will Break if something changes the
> primitive number". I can only find MethodContext>>isHandlerContext caring
> about the particular primitive number)
>
> Could one, in principle at least, lose the primitive invocation and have an
> instvar isHandlerContext on ContextPart (MethodContext, more likely), and
> just repeatedly walk down the stack to find the handler rather than using
> another primitive to find the handler?
>
> Secondly, what's handlerActive for in #on:do:? It's a local variable set and
> then never referenced. (No other method has 'handlerActive' in its source,
> in the base image.)
>
> Thanks!
>
> frank
>
>