Re: Exception Handling (Mike Stump)
18 Sep 1998 23:03:08 -0400

          From comp.compilers

Related articles
[5 earlier articles]
Re: Exception Handling (journeyman) (2002-08-04)
Re: Exception Handling (Nick Maclaren) (2002-08-10)
Re: Exception Handling (Marco van de Voort) (2002-08-10)
Re: Exception Handling (Maxim Reznik) (2002-08-10)
Re: Exception Handling (Fergus Henderson) (2002-08-14)
Exception Handling (Bernhard Tschirren) (1998-09-13)
Re: Exception Handling (1998-09-18)
Re: Exception Handling (1998-09-18)
Re: Exception Handling (1998-09-18)
Re: Exception Handling (Morten Christensen) (1998-09-26)
| List of all articles for this month |

From: (Mike Stump)
Newsgroups: comp.compilers
Date: 18 Sep 1998 23:03:08 -0400
Organization: Kithrup Enterprises, Ltd.
References: 98-09-049
Keywords: errors

Bernhard Tschirren <> wrote:
>Could somebody please explain "zero runtime overhead" exception handling.
>Im only familiar with the traditional setjmp() / longjmp() methods.
>[I thought the code was instrumented with a table that the exception
>handler consulted to figure out which exception handler to use. -John]

Right, thought that may be too short for a newcomer to understand.

Imagine a table that is index by PC ranges that contains a handler to
jump to, should the PC be within that range. When compiling code, you
arrange for all code blocks to be bracketed by handlers. For a
function body, its handler unwinds the function call. When selecting
a handler, you pick the innermost handler (the tightest range).

Advantage, no inline code to manage EH variable stack, or
activations/deactivations. It is managed solely by the PC contents.

If you want to see this in action, get g++ (, and
compile something up. -fsjlj-exceptions will select the setjmp style
cost you will recognize, and -fno-sjlj-exceptions will select the zero
overhead scheme.

There are tons more details and various optimizations that can be
done, but you get the idea.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.