Raising Exceptions

Asynchronous exceptions that have been deferred in a must-complete section are dispatched automatically by the system when the thread exits the must-complete section. However, a synchronous exception that has been deferred must be raised by calling DosRaiseException.

DosRaiseException can also be used to simulate either an asynchronous or synchronous exception. For example, a floating point emulator (a program that emulates a numeric coprocessor) can use this function to simulate an NPX exception.

Raising a software exception captures the machine state of the current thread in a ContextRecord data structure. The ExceptionAddress field of EXCEPTIONREPORTRECORD is set to the return address of the caller, as are the corresponding fields of the ContextRecord data structure. The system then calls each exception handler on the list, passing each a pointer to EXCEPTIONREPORTRECORD and the created ContextRecord data structures. In the case of a continuable exception for which XCPT_CONTINUE_EXECUTION is returned, DosRaiseException restores the potentially modified context back into the machine before returning. Note that control cannot return to the caller of DosRaiseException if the instruction pointer in ContextRecord has been modified.

The caller of DosRaiseException can set the EH_NONCONTINUABLE bit in the flags field of the EXCEPTIONREPORTRECORD data structure. By doing so, the caller guarantees that it is never returned to after the call to DosRaiseException. Note that once set, the EH_NONCONTINUABLE bit cannot be modified by any exception handler. The system will enforce this.

Following are some possible scenarios that might occur after a call to DosRaiseException has been made:

• If one of the exception handlers returns from a continuable exception with a status of XCPT_CONTINUE_EXECUTION, DosRaiseException returns NO_ERROR to the caller, and the thread resumes execution.

• If one of the exception handlers returns from a noncontinuable exception with a status of XCPT_CONTINUE_EXECUTION, the process is terminated, because it is illegal to return XCPT_CONTINUE_EXECUTION from a noncontinuable exception.

• If none of the exception handlers in the thread's chain of handlers returns with a status of XCPT_CONTINUE_EXECUTION, then the action taken depends on the exception number:

  • If the exception number indicates a user-assigned exception or an unassigned system exception, the process is terminated.

  • If the exception number is assigned to a system exception, and CS:EIP points to 32-bit code, no 16-bit handlers are called and the system default action is taken. Depending on which system exception has been raised, the default action is either to terminate the process, or to continue execution of the thread with NO_ERROR returned to the caller.

  • If the exception number is assigned to a system exception that maps to a 16-bit exception and CS:EIP points to 16-bit code, a 16-bit exception handler is called, if one is registered. Otherwise OS/2 takes the default action.

  ---

  [Back: Sending Signal Exceptions]
  [Next: User-Defined Exceptions]