• Exception handling

• Unwinding

The next sections cover the following topics:

• Requirements for exception handling

• An overview of exception handling

• The kinds of exceptions

• Status values and exception codes

• Exception records

• Frame-based exception handlers

• How handlers become established

• How exceptions are raised

• The search for and invocation of exception handlers

• Modification of exception records and context by handlers

• Handler completion and return value

• Exception synchronization and continuation from exceptions

• Coexistence of exception and signal handling

• EXCEPTION_UNWINDING

• EXCEPTION_EXIT_UNWIND

• EXCEPTION_TARGET_UNWIND

The ExceptionCode for unwind exceptions contains the reason code for the unwind along with any supplied qualifiers. This information is similar to the contents of the ExceptionCode field for general exceptions.

The frame-based exception handlers that can be invoked are those established by active procedures, from the most current procedure to the oldest predecessor.

An exception handler that conforms to this calling standard should not handle any exception that its establisher did not cause, unless there is a prior agreement between the writers of the exception handler and the writers of the code that raised the exception.

Exceptions can be raised and unwind operations that cause exception handlers to be called can occur when the current value of at least one variable is in a register rather than in memory. Therefore, a handler and any descendant procedure called directly or indirectly by a handler must not access any variables except those explicitly passed to the procedure as arguments or those that exist in the normal scope of the procedure.

This requirement can be violated for specific memory locations only by agreement between the handler and all procedures that might access those memory locations. The effects of such agreements are not specified by this calling standard.

exc_raise_exception (ExceptionRecord)

Arguments:

Function Value:

(*ExceptionHandler)
    ( ExceptionRecord, EstablisherFrame,
                          ContextRecord, DispatcherContext )

Arguments:

Function Value:

• ControlPC

  This field contains the program counter (PC) where control left the establisher of the exception handler; that is, the PC of the call instruction or the instruction that caused the exception. This field can be updated by a handler. If a nested exception occurs during unwinding while the handler is still active, the value of the PC used for the establisher will be the updated value of ControlPC. This mechanism can be employed to retire nested exception handling scopes that are local to a procedure in order to assure that each is executed only once at most (even in the presence of a nested exception within such a handler). The ControlPC value must, however, always be an address within the procedure whose handler is executing.

• collide_info

  This field is a quadword whose meaning is determined by the handler. Typically, a language-specific handler will write new values into this field as it processes nested scopes. If a colliding unwind occurs, the dispatcher sets collide_info to the value it had for the establisher. A handler knows to read this field when EXCEPTION_COLLIDED_UNWIND is 1. This field can be used in the same manner as the ControlPC field to retire nested exception scopes, but it does not have to be an address within the current procedure.

• FunctionEntry

  This field contains a pointer to the procedure descriptor for the establisher. The field is read-only to exception handlers, except for handlers for the exception dispatcher itself.

The effects of a handler-modifying passed exception information are as follows:

• If the EXCEPTION_NONCONTINUABLE flag in the primary exception record is changed from 0 to 1, the exception handler that made the modification must not return ExceptionContinueExecution, nor can any handler subsequently invoked for the exception return ExceptionContinueExecution.

  If ExceptionContinueExecution is returned after the EXCEPTION_NONCONTINUABLE flag has been changed from 0 to 1, a nested exception is raised with ExceptionCode equalling EXC_STATUS_NONCONTINUABLE_EXCEPTION, indicating that an attempt was made to continue from a noncontinuable exception. This second exception is also noncontinuable.

• If any flags in ExceptionFlags in the primary exception record are modified except as described in the previous item in this list, there is no effect after the exception handler completes its operation. All handlers subsequently invoked for the exception receive a primary exception record with the flags unmodified.

  However, an exception handler must not change the EXCEPTION_NONCONTINUABLE flag from 1 to 0.

• If the contents of the record specified by ContextRecord or DispatcherContext are modified by a handler, except for ControlPC and collide_info, the results are unpredictable and such a handler does not conform to this calling standard.

• Except as specified in the previous items in this list, all changes made to the exception information will be visible to handlers subsequently invoked for the exception. Any other effects of modifying the exception information are not defined by this calling standard.

• Reraises the exception

• Continues execution of the thread

• Initiates procedure invocation unwinding

• Correct and predictable nonlocal GOTOs in a multilanguage environment

• Construction of modular, maintainable multilanguage applications

This section discusses the following topics:

• Overview of unwinding

• Types of unwind operations

• Types of unwind invocation

• Unwind initiation

• Multiply active unwind operations

• Unwind completion

• Unwind coexistence with setjmp() and longjmp()

Before control is transferred to the unwind target location, the unwind support code invokes all frame-based handlers that were established by procedure invocations which are being terminated, as well as the handler for the target invocation.

This behavior gives each procedure invocation the chance to perform clean-up processing before its context is lost. These handlers are invoked with an indication that an unwind is in progress. The exception record passed to the target invocation's handler also has EXCEPTION_TARGET_UNWIND set to 1.

Once all the relevant frame-based handlers have been called and the appropriate frames have been removed from existence, the target invocation's saved context is restored and execution is resumed at the specified location.

The results of attempting an unwind operation to any invocation previous to the top-level procedure of a thread are undefined by this calling standard.

Unwinding does not require an exception handler to be active. Unwind operations can be used by languages to implement nonlocal GOTOs.

Because of this need to clean up shared resources, exiting by a user-mode thread can be accomplished only by unwinding. A special type of unwind, called an exit unwind, performs the following actions to terminate execution:

• Invokes all established frame-based handlers, passing them an exception record that specifies that an exit unwind is in progress.

• Terminates all procedure invocations up to the beginning of the call chain.

• Terminates the execution of the thread.

Threads that use any mechanism for termination other than the normal return process are not considered to be standard and their behavior is undefined.

exc_unwind (VirtualTargetFrame, TargetPC,
                            ExceptionRecord, ReturnValue)

exc_unwind_rfp (RealTargetFrame, TargetPC,
                            ExceptionRecord, ReturnValue)

Arguments:

Function Value:

An unwind that is initiated while a previous unwind is active is either a nested unwind or a colliding unwind. This section discusses both types of multiply active unwind operations.

When a nested unwind is initiated, no special rules apply. The nested unwind operation proceeds as a normal unwind operation. When execution resumes at the target location of the nested unwind, the nested unwind is complete and the previous unwind is once again the most current unwind operation.

A colliding unwind is detected when the most current active unwind handler is terminated. This detection of a colliding unwind is referred to as a collision. When a collision occurs, the second (more recent) unwind operation takes precedence and the previous unwind is abandoned.

The next action is to reinvoke the most current established handler because its establisher has not been unwound. The EXCEPTION_COLLIDED_UNWIND flag is set in the exception record to indicate this situation to the handler.

• The target procedure invocation is the most current invocation in the procedure invocation chain.

• The environment of the target invocation is restored to the state that existed when that invocation was last current, except for the contents of scratch registers.

• The GP register contains a pointer to the GOT that is appropriate to the target procedure.

• The $0 register contains the return value that was passed by the routine which invoked the unwind.

• Execution continues at the target location.