--- wednesday 11-may-11, John McCall <rjmccall at apple.com> wrote:
> >
> > However, it has always seemed to me that exception
> handling (at least on c++) is just a particular syntax of a
> subset of coroutine semantics:
>
> This is certainly one way of implementing exceptions.
> Unfortunately, it would be prohibitively expensive to create
> a new coroutine every time a new EH scope is entered —
> much worse than other explicit scope-tracking
> implementations like SEH or builtin_sj/lj.
I completely agree on this, but it seems to me that all the exception
specific context switchs are no more than a list of specific optimization
scenarios where one can trim certain aspects of the context switch.
It seems to me that the idea of language-specific exceptions is a too high level
concept to be embedded in a compiler toolkit. Your post seemed to me to
represent the right intentions regarding design goals; trying to keep the
exception system as general as possible
My post only purpose was to highlight that in regards of design principles, you
can implement basically any sort of exception system by a set of context
switches; certainly good design is just but one goal and this approach might be
overlooking the performance and conformance constraints in ways i don't
completely understand.
Regarding something more concrete, here is a scenario for you to consider in
your architectural design: suppose a user wants to serialise an execution
context to disk (meaning that objects in the stack frame need to be serialised
individually). In this case, it would pay that you have a generic way to visit
the stack frames and invoke some operations other than cleanup.
hope this helps,
Charles
>
> That said, lowering IR from a "conventional" style —
> where cleanups appear as normal code and control
> dependencies are expressed directly with normal-ish control
> flow — to the form required by an SEH-like implementation
> would indeed require operations not fundamentally dissimilar
> from coroutine extraction.
>
