| Using VISA.NET > API Structure > Exceptions |
VISA.NET uses exceptions rather than return codes to report errors. Exceptions generally include a variety of information about the error that occurred, and they propagate up the call stack automatically until they are handled. With exceptions, there is no need to check a return code after every call to see if an error occurred.
While the VISA specification attempts to describe all of the status codes that can be returned by a function, this is impractical in VISA.NET for several reasons, primarily because implementations of VISA.NET features vary. Also, some standard exceptions are so common that documenting them for every method would clutter the documentation. The information on this page will help you understand what exceptions may be thrown.
VISA.NET uses .NET Framework exceptions extensively. All exceptions (including all .NET Framework exceptions) derive from System.Exception, which provides a common set of capabilities to all exceptions. Many derived exceptions add additional properties for information, but this is not a requirement; exceptions may only differ from this base exception by a name that indicates the reason for the exception.
Some of the more frequently used .NET exceptions include:
The .NET Framework defines many other exceptions. Never assume that you can predict all of the exceptions that might be thrown by a .NET method or property, and always remember that unhandled exceptions will terminate the program. Do not catch all exceptions by catching System.Exception. Instead, catch specific exceptions which indicate failure conditions from which your program can recover (e.g., Ivi.Visa.IOTimeoutException), and let other exceptions propagate up the stack. Some exceptions (such as System.ExecutionEngineException) should not be caught.
The Ivi.Visa namespace defines four exceptions:
The Keysight.Visa namespace does not define any exceptions at this time.
.NET exceptions provide an elegant way of reporting errors to calling programs. Exceptions include more information about errors than simple error codes, and require less processing until the calling code is actually ready to deal with them.
The value of exceptions can be seen in contrast to the way that VISA C handles errors. Every VISA C function returns an integer status code. The status code may indicate success, a warning condition, or an error. If you need additional information, you can retrieve an error message, but the usefulness of the error message is limited by the amount of information it can contain. After each call to a VISA function, you check the status code to see if an error occurred during the call. Often there is nothing the calling function can do to handle the error, so if an error is found it just returns to the function that called it, and so on. This continues until a function in the stack can handle the error, or until the program ends with an error return code. The additional code needed to check for error return codes makes programs cumbersome, and though techniques have been developed over the years to reduce this burden, it is still less than ideal.
.NET exceptions, on the other hand, contain a wealth of information about the error including:
Once .NET code throws an exception, the .NET runtime propagates the exception up the stack until the calling program explicitly catches it. There is no need to check for exceptions at each intermediate level in the calling hierarchy. This mechanism eliminates cumbersome code that checks for errors, but can't respond to them.