I'm pondering improved error handling in my LabVIEW interface to HDF5, and I'm wondering if there are any guarantees to be had on HDF5s error codes. I note that the major and minor error codes are simply sequential numbers ored with 0x0C000000.
The question: is there any guaranteed that the symbol -> number mapping (e.g. H5E_CANTALLOC -> 0x0C000nnn) will remain constant from version to version of the toolkit, or even from one person's build to another? As far as I can tell, the answer is "no," but I'm hoping its "yes."
Jason
Hi Jason,
I'm pondering improved error handling in my LabVIEW interface to HDF5, and
I'm wondering if there are any guarantees to be had on HDF5s error codes. I
note that the major and minor error codes are simply sequential numbers ored
with 0x0C000000.
The question: is there any guaranteed that the symbol -> number mapping
(e.g. H5E_CANTALLOC -> 0x0C000nnn) will remain constant from version to
version of the toolkit, or even from one person's build to another? As far
as I can tell, the answer is "no," but I'm hoping its "yes."
I'm not a core HDF developer, but my impression is that in HDF5 1.8.X
the "error codes" are now actually HDF5 identifiers, which are
initialized when the library starts up. So the exact values are
presumably not guaranteed to be the same even across program launches.
In the h5py library, we build a dictionary mapping the error codes to
Python exception classes when the Python module is imported. You
could do something similar, for example populating a C array with the
error codes and then indexing into it to find a particular value.
Andrew
Hi Andrew,
Well, it's nice to know we've had similar thoughts. I decided to go with a mapping to strings rather than numbers, though. I generate a bidirectional mapping between the string symbols (e.g. H5E_CANTCONVERT) and the actual number. This seems like it should be generally robust against future changes in the library, and I'm not particularly concerned about speed when it comes to handling errors. It still is a bit of a maintenance headache for me, as I need to keep the list of error strings up to date with each new version, but that's not the end of the world.
Jason
ยทยทยท
On 11/7/2014 2:36 PM, Andrew Collette wrote:
Hi Jason,
I'm pondering improved error handling in my LabVIEW interface to HDF5, and
I'm wondering if there are any guarantees to be had on HDF5s error codes. I
note that the major and minor error codes are simply sequential numbers ored
with 0x0C000000.
The question: is there any guaranteed that the symbol -> number mapping
(e.g. H5E_CANTALLOC -> 0x0C000nnn) will remain constant from version to
version of the toolkit, or even from one person's build to another? As far
as I can tell, the answer is "no," but I'm hoping its "yes."
I'm not a core HDF developer, but my impression is that in HDF5 1.8.X
the "error codes" are now actually HDF5 identifiers, which are
initialized when the library starts up. So the exact values are
presumably not guaranteed to be the same even across program launches.
In the h5py library, we build a dictionary mapping the error codes to
Python exception classes when the Python module is imported. You
could do something similar, for example populating a C array with the
error codes and then indexing into it to find a particular value.
Andrew
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5
