Exception handling functions can be directly associated with exceptions, just as console control handlers can be associated with console control events. When an exception occurs, the vectored exception handlers are called first, before the system unwinds the stack to look for structured exception handlers. No keywords, such as __try and __catch, are required.
Vectored exception handling (VEH) management is similar to console control handler management, although the details are different. Add, or “register,” a handler using AddVectoredExceptionHandler.
PVOID WINAPI AddVectoredExceptionHandler ( ULONG FirstHandler, PVECTORED_EXCEPTION_HANDLER VectoredHandler)
|
Handlers can be chained, so the FirstHandler parameter specifies that the handler should either be the first one called when the exception occurs (nonzero value) or the last one called (zero value). Subsequent AddVectoredExceptionHandler calls can update the order. For example, if two handlers are added, both with a zero FirstHandler value, the handlers will be called in the order in which they were added.
The return value is a handler to the exception handler (NULL indicates failure). This handle is the sole parameter to RemoveVectoredExceptionHandler, which returns a non-NULL value if it succeeds.
The successful return value is a pointer to the exception handler, that is, -VectoredHandler. A NULL return value indicates failure.
VectoredHandler is a pointer to the handler function of the form:
LONG WINAPI VectoredHandler (PEXCEPTION_POINTERS ExceptionInfo)
|
PEXCEPTION_POINTERS is the address of an EXCEPTION_POINTERS structure with processor-specific and general information.
A VEH handler function should be fast so that the exception handler will be reached quickly. In particular, the handler should never access a synchronization object that might block the thread, such as a mutex . In most cases, the VEH simply accesses the exception structure, performs some minimal processing (such as setting a flag), and returns. There are two possible return values, both of which are familiar from the SEH discussion.
EXCEPTION_CONTINUE_EXECUTION— No more handlers are executed, SEH is not performed, and control is returned to the point where the exception occurred. As with SEH, this may not always be possible or advisable.
EXCEPTION_CONTINUE_SEARCH— The next VEH handler, if any, is executed. If there are no additional handlers, the stack is unwound to search for SEH handlers.