 |
HDF5
1.14.4.3
API Reference
|
|
|
HDF5
1.14.4.3
API Reference
|
|
The HDF5 library provides an error reporting mechanism for both the library itself and for user application programs. It can trace errors through function stack and error information like file name, function name, line number, and error description.
The HDF5 Library provides an error reporting mechanism for both the library itself and for user application programs. It can trace errors through function stack and error information like file name, function name, line number, and error description.
Basic Error Handling Operations discusses the basic error concepts such as error stack, error record, and error message and describes the related API functions. These concepts and functions are sufficient for application programs to trace errors inside the HDF5 Library.
Advanced Error Handling Operations talks about the advanced concepts of error class and error stack handle and talks about the related functions. With these concepts and functions, an application library or program using the HDF5 Library can have its own error report blended with HDF5's error report.
Starting with Release 1.8, we have a new set of Error Handling API functions. For the purpose of backward compatibility with version 1.6 and before, we still keep the old API functions, H5Epush1, H5Eprint1, H5Ewalk1, H5Eclear1, H5Eget_auto1, H5Eset_auto1. These functions do not have the error stack as a parameter. The library allows them to operate on the default error stack. (The H5E compatibility macros will choose the correct function based on the parameters)
The old API is similar to functionality discussed in Basic Error Handling Operations. The functionality discussed in Advanced Error Handling Operations,the ability of allowing applications to add their own error records, is the new design for the Error Handling API.
This section is under construction.
Let us first try to understand the error stack. An error stack is a collection of error records. Error records can be pushed onto or popped off the error stack. By default, when an error occurs deep within the HDF5 Library, an error record is pushed onto an error stack and that function returns a failure indication. Its caller detects the failure, pushes another record onto the stack, and returns a failure indication. This continues until the API function called by the application returns a failure indication. The next API function being called will reset the error stack. All HDF5 Library error records belong to the same error class. For more information, see Advanced Error Handling Operations.
In normal circumstances, an error causes the stack to be printed on the standard error stream automatically. This automatic error stack is the library's default stack. For all the functions in this section, whenever an error stack ID is needed as a parameter, H5E_DEFAULT can be used to indicate the library's default stack. The first error record of the error stack, number #000, is produced by the API function itself and is usually sufficient to indicate to the application what went wrong.
|
If an application calls H5Tclose on a predefined datatype then the following message is printed on the standard error stream. This is a simple error that has only one component, the API function; other errors may have many components. HDF5-DIAG: Error detected in HDF5 (1.10.9) thread 0. #000: H5T.c line ### in H5Tclose(): predefined datatype major: Function argument minor: Bad value
|
In the example above, we can see that an error record has a major message and a minor message. A major message generally indicates where the error happens. The location can be a dataset or a dataspace, for example. A minor message explains further details of the error. An example is “unable to open file”. Another specific detail about the error can be found at the end of the first line of each error record. This error description is usually added by the library designer to tell what exactly goes wrong. In the example above, the “predefined datatype” is an error description.
Besides the automatic error report, the error stack can also be printed and cleared by the functions H5Eprint2 and H5Eclear2. If an application wishes to make explicit calls to H5Eprint2 to print the error stack, the automatic printing should be turned off to prevent error messages from being displayed twice (see H5Eset_auto2).
To print an error stack:
This function prints the error stack specified by error_stack on the specified stream, stream. If the error stack is empty, a one‐line message will be printed. The following is an example of such a message. This message would be generated if the error was in the HDF5 Library.
To clear an error stack:
The H5Eclear2 function shown above clears the error stack specified by error_stack. H5E_DEFAULT can be passed in to clear the current error stack. The current stack is also cleared whenever an API function is called; there are certain exceptions to this rule such as H5Eprint2.
Sometimes an application calls a function for the sake of its return value, fully expecting the function to fail; sometimes the application wants to call H5Eprint2 explicitly. In these situations, it would be misleading if an error message were still automatically printed. Using the H5Eset_auto2 function can control the automatic printing of error messages.
To enable or disable automatic printing of errors:
The H5Eset_auto2 function can be used to turn on or off the automatic printing of errors for the error stack specified by error_stack. When turned on (non‐null func pointer), any API function which returns an error indication will first call func, passing it client_data as an argument. When the library is first initialized the auto printing function is set to H5Eprint2 and client_data is the standard error stream pointer, stderr.
To see the current settings:
The function above returns the current settings for the automatic error stack traversal function, func, and its data, client_data. If either or both of the arguments are null, then the value is not returned.
An application can temporarily turn off error messages while “probing” a function. See the example below.
Example: Turn off error messages while probing a function
Or automatic printing can be disabled altogether and error messages can be explicitly printed.
Example: Disable automatic printing and explicitly print error messages
Applications are allowed to define an automatic error traversal function other than the default H5Eprint(). For instance, one can define a function that prints a simple, one‐line error message to the standard error stream and then exits. The first example below defines a such a function. The second example below installs the function as the error handler.
Example: Defining a function to print a simple error message
Example: The user‐defined error handler
The H5Eprint2 function is actually just a wrapper around the more complex H5Ewalk function which traverses an error stack and calls a user‐defined function for each member of the stack. The example below shows how H5Ewalk is used.
The error stack err_stack is traversed and func is called for each member of the stack. Its arguments are an integer sequence number beginning at zero (regardless of direction) and the client_data pointer. If direction is H5E_WALK_UPWARD, then traversal begins at the inner‐most function that detected the error and concludes with the API function. Use H5E_WALK_DOWNWARD for the opposite order.
An error stack traversal callback function takes three arguments: n is a sequence number beginning at zero for each traversal, eptr is a pointer to an error stack member, and client_data is the same pointer used in the example above passed to H5Ewalk. See the example below.
The H5E_error2_t structure is shown below.
The maj_num and min_num are major and minor error IDs, func_name is the name of the function where the error was detected, file_name and line locate the error within the HDF5 Library source code, and desc points to a description of the error.
The following example shows a user‐defined callback function.
Example: A user‐defined callback function
If a C routine that takes a function pointer as an argument is called from within C++ code, the C routine should be returned from normally.
Examples of this kind of routine include callbacks such as H5Pset_elink_cb and H5Pset_type_conv_cb and functions such as H5Tconvert and H5Ewalk2.
Exiting the routine in its normal fashion allows the HDF5 C Library to clean up its work properly. In other words, if the C++ application jumps out of the routine back to the C++ “catch” statement, the library is not given the opportunity to close any temporary data structures that were set up when the routine was called. The C++ application should save some state as the routine is started so that any problem that occurs might be diagnosed.
The section above, see Basic Error Handling Operations, discusses the basic error handling operations of the library. In that section, all the error records on the error stack are from the library itself. In this section, we are going to introduce the operations that allow an application program to push its own error records onto the error stack once it declares an error class of its own through the HDF5 Error API.
|
An error report shows both the library's error record and the application's error records. See the example below.
Error Test-DIAG: Error detected in Error Program (1.0)
thread 8192:
#000: ../../hdf5/test/error_test.c line ### in main():
Error test failed
major: Error in test
minor: Error in subroutine
#001: ../../hdf5/test/error_test.c line ### in
test_error(): H5Dwrite failed as supposed to
major: Error in IO
minor: Error in H5Dwrite
HDF5-DIAG: Error detected in HDF5 (1.10.9) thread #####:
#002: ../../hdf5/src/H5Dio.c line ### in H5Dwrite():
not a dataset
major: Invalid arguments to routine
minor: Inappropriate type
|
In the line above error record #002 in the example above, the starting phrase is HDF5. This is the error class name of the HDF5 Library. All of the library's error messages (major and minor) are in this default error class. The Error Test in the beginning of the line above error record #000 is the name of the application's error class. The first two error records, #000 and #001, are from application's error class. By definition, an error class is a group of major and minor error messages for a library (the HDF5 Library or an application library built on top of the HDF5 Library) or an application program. The error class can be registered for a library or program through the HDF5 Error API. Major and minor messages can be defined in an error class. An application will have object handles for the error class and for major and minor messages for further operation. See the example below.
Example: The user‐defined error handler
The Error API has functions that can be used to register or unregister an error class, to create or close error messages, and to query an error class or error message. These functions are illustrated below.
To register an error class:
This function registers an error class with the HDF5 Library so that the application library or program can report errors together with the HDF5 Library.
To add an error message to an error class:
This function adds an error message to an error class defined by an application library or program. The error message can be either major or minor which is indicated by parameter msg_type.
To get the name of an error class:
This function retrieves the name of the error class specified by the class ID.
To retrieve an error message:
This function retrieves the error message including its length and type.
To close an error message:
This function closes an error message.
To remove an error class:
This function removes an error class from the Error API.
The example below shows how an application creates an error class and error messages.
Example: Create an error class and error messages
The example below shows how an application closes error messages and unregisters the error class.
Example: Closing error messages and unregistering the error class
An application can push error records onto or pop error records off of the error stack just as the library does internally. An error stack can be registered, and an object handle can be returned to the application so that the application can manipulate a registered error stack.
To register the current stack:
This function registers the current error stack, returns an object handle, and clears the current error stack. An empty error stack will also be assigned an ID.
To replace the current error stack with another:
This function replaces the current error stack with another error stack specified by error_stack and clears the current error stack. The object handle error_stack is closed after this function call.
To push a new error record to the error stack:
This function pushes a new error record onto the error stack for the current thread.
To delete some error messages:
This function deletes some error messages from the error stack.
To retrieve the number of error records:
This function retrieves the number of error records from an error stack.
To clear the error stack:
This function clears the error stack.
To close the object handle for an error stack:
This function closes the object handle for an error stack and releases its resources.
The example below shows how an application pushes an error record onto the default error stack.
Example: Pushing an error message to an error stack
The example below shows how an application registers the current error stack and creates an object handle to avoid another HDF5 function from clearing the error stack.
Example: Registering the error stack
Previous Chapter HDF5 Attributes - Next Chapter Properties and Property Lists in HDF5
1.9.7