Regarding _ContinueUnwind ..

I haven't heard of anything like this either - tho' I'll poke around a bit. Another (baroque) feature - it may be useful to continue the unwind with a different return value.

I think in most cases an implicit _ContinueUnwind should be performed, so I'd probably put one into the Self wrapper on _UnwindProtect and (if merited have some extra syntax for "dont unwind" ).

However, I recall a article by someone from ParcPlace (L. Peter Deutsch) talking about the design of the new Smalltalk exception mechanism (I'm at home, references are at work). I think the main point was that although his design allowed things like restartable exceptions with fine control, this was unnecessary in pratice and ended up complicating matters, requiring extra housekeeping (comments from the more knowledgeable warmly invited).

Also, non local returns that can end up anywhere are quite a significant addition to the programming model. Though they may turn out to be useful, I'm not sure how they fit in with the minimalist aesthetics of Self.

Urs writes

Though less flexible than the first proposal, this solution seems more intuitive and easier to understand. Comments?

See above, but ultimately, I'd vote for whatever's easiest to do. I thought _ContinueUnwind was a bit strange at first, but the last time I raised this with the group, someone mentioned that there may be problems building unwindProtect with the current arrangement primitives in the compiler. So I figured that the _ContinueUnwind was just a way of getting around these problems :-)

Merry Christmas

James