User`s guide

Programming with VISA 3
Agilent VISA User’s Guide 71
3 Code in any operation (after calling an exception handler) may not be
called if the handler does not return. For example, local allocations
must be freed before invoking the exception handler, rather than after
it.
One situation in which an exception event will not be generated is in the
case of asynchronous operations. If the error is detected after the
operation is posted (i.e., once the asynchronous portion has begun), the
status is returned normally via the I/O completion event.
However, if an error occurs before the asynchronous portion begins (i.e.,
the error is returned from the asynchronous operation itself), then the
exception event will still be raised. This deviation is due to the fact that
asynchronous operations already raise an event when they complete,
and this I/O completion event may occur in the context of a separate
thread previously unknown to the application. In summary, a single
application event handler can easily handle error conditions arising from
both exception events and failed asynchronous operations.
Using the VI_EVENT_EXCEPTION Event
You can use the VI_EVENT_EXCEPTION event as notification that an
error condition has occurred during an operation invocation. The
following table describes the VI_EVENT_EXCEPTION event
attributes.
Example: Exception Events /* This is an example of
how to use exception
events to trap VISA errors. An exception event
Table 19 VI_EVENT_EXCEPTION Event Attributes.
Attribute Name Access Privilege Data Type Range Default
VI_ATTR_EVENT_TYPE RO Global ViEventType VI_EVENT_EXCEPTIO
N
N/A
VI_ATTR_STATUS RO Global ViStatus N/A N/A
VI_ATTR_OPER_NAME RO Global ViString N/A N/A