how does exception mechanism work?

[bobueland]

Sometimes the best way to understand something is to understand the
mechanism behind it. Maybe that is true for exceptions. This is a model
I have right now (which probably is wrong)

1. When a runtime error occurs, some function (probably some class
method) in Python is called behind the scenes.
2. That function goes into a global table having error types in one
column and corresponding flags in another (and probably other columns
used for trace back information). It sets the flag for the error type
that occured.
3. Then the function looks if the error occured inside a try statement
(in the current function or the function that called the current
function, or the one that called that function and so on). If it did
occur inside a try statement it looks if the corresponding exception
handles the occured error type and if so it executes the statements
under the exception clause. The function also resets the type error
flag.
4. If no try statement is found in 3. (or no exception handling the
occured type error) then it is an unhandled error and the Python stops
the execution, prints an error message and resets the global type error
flag)

Is this model correct or wrong? Where can I read about the mechanism
behind exceptions?

Bob

[Paul Rubin]

bo*******@yahoo.com writes:

Is this model correct or wrong? Where can I read about the mechanism
behind exceptions?

Usually you push exception handlers and "finally" clauses onto the
activation stack like you push return addresses for function calls.
When something raises an exception, you scan the activation stack
backwards, popping stuff from it as you scan and executing "finally"
clauses as you find them, until you find a handler for the raised
exception.

Good book: "Structure and Interpretation of Computer Programming"
by Abelson and Sussman,

http://mitpress.mit.edu/sicp/

It explains all this stuff (uses a different language from Python, but
principles are similar). Full text is online.

[Tom Anderson]

On Mon, 12 Dec 2005, it was written:

bo*******@yahoo.com writes:

Is this model correct or wrong? Where can I read about the mechanism
behind exceptions?

Usually you push exception handlers and "finally" clauses onto the
activation stack like you push return addresses for function calls. When
something raises an exception, you scan the activation stack backwards,
popping stuff from it as you scan and executing "finally" clauses as you
find them, until you find a handler for the raised exception.

That varies an awful lot, though - AIUI, in java, the catch blocks are
specified sort of in the same place as the code; a method definition
consists of bytecode, a pile of metadata, and an exception table, which
says 'if an exception of type x happens at a bytecode in the range a to b,
jump to bytecode c'. When the exception-handling machinery is walking the
stack, rather than looking at some concrete stack of exception handlers,
it walks the stack of stack frames (or activation records or whatever you
call them), and for each one, follows the pointer to the relevant method
definition and inspects its exception table. Finally blocks are handled by
putting the finally's code right after the try's code in the normal flow
of execution, then concocting an exception handler for the try block which
points into the finally block, so however the try block finishes,
execution goes to the finally block.

The advantage of this approach over an explicit stack of handlers is that,
although unwinding the stack is perhaps a bit slower, due to having to
chase more pointers to get to the exception table, there's zero work to be
done to set up a try block, and since executing a try is a lot more
frequent than executing a throw-catch, that's a win.

Of course, that's how the conceptual virtual machine does it; real
implementations don't necessarily do that. That said, it is a traditional
superstition in java that a try block is essentially free, which would
suggest that this sort of implementation is common. Indeed, i see no
reason why it wouldn't be - i think the push-a-handler style seen in C/C++
implementations is only necessary because of the platform ABI, which
doesn't usually mandate a standard layout for per-function metadata.

tom

--
limited to concepts that are meta, generic, abstract and philosophical --
IEEE SUO WG

[Ben Hutchings]

Tom Anderson <tw**@urchin.earth.li> wrote:

On Mon, 12 Dec 2005, it was written:

bo*******@yahoo.com writes:

Is this model correct or wrong? Where can I read about the mechanism
behind exceptions?
Usually you push exception handlers and "finally" clauses onto the
activation stack like you push return addresses for function calls. When
something raises an exception, you scan the activation stack backwards,
popping stuff from it as you scan and executing "finally" clauses as you
find them, until you find a handler for the raised exception.

That varies an awful lot, though - AIUI, in java, the catch blocks are
specified sort of in the same place as the code; a method definition
consists of bytecode, a pile of metadata, and an exception table, which
says 'if an exception of type x happens at a bytecode in the range a to b,
jump to bytecode c'.

<snip> i think the push-a-handler style seen in C/C++
implementations is only necessary because of the platform ABI, which
doesn't usually mandate a standard layout for per-function metadata.

Most platform ABIs have only covered C, which doesn't have any
exception-handling (though POSIX threads sort of requires it). The
only platform ABIs I'm aware of that require pushing handlers are the
Win32 ABIs. I believe the technique of pushing exception handler
records on the stack was used because it was relatively obvious and
initially not too expensive (since few exception handlers were used).

FWIW, most C++ implementations now use range tables, as you described.
So do the Win64 ABIs and the Unix/Linux IA64 ABI.

--
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.