The error numbers for certain operations changed in HDF5 1.10.3 from H5E_ARGS, H5E_BADTYPE to H5E_SYM, H5E_BADTYPE. This precipitated test failures for the h5py Python wrapper, because the error numbers are used to translate HDF5 errors into Python exceptions.
There’s a bug report with more details here: https://github.com/h5py/h5py/issues/1088.
We can fix the test by mapping H5E_SYM, H5E_BADTYPE to the same exception class. But those error numbers are used in numerous places in the HDF5 codebase, so changing which exception this translates to may affect all kinds of operations.
Are the error numbers for particular errors considered part of HDF5’s API? If so, is it a bug that these error numbers changed in a minor version?
Hi @thomas1,
I apologize for the delayed response. As what was told to me was put succinctly, I will repeat it here:
“Error stacks are not designed to be stored, they are a runtime-only scoped object. The symbols (H5E_ARGS) are part of the API, but the order and information of error info in the error stack is not (and has never been) part of the “public API”. That information can change at any time, due to new development, bug fixes, refactoring, etc.”
The change that occurred between 1.10.2 and 1.10.3 was most likely just cleanup work done in order to make the major error code be more consistent with what seemed the appropriate choice for the given section of code. While I’d like to be able to say that our choice for these major and minor error codes is fixed, the reality is that they often change for various reasons. Among these might be the following:
-
The major and/or minor error code chosen when the code was first written might have been chosen inappropriately (e.g. H5E_DATASET used for the major error code inside HDF5 Group-related functionality)
-
The relevant code is re-written such that the error code needs to change to accommodate the revisions
-
A new, more appropriate major/minor error code is introduced OR a decision is made that a different major/minor error code may be more appropriate; thus the error code used will be changed
As you can see, these aren’t set in stone and it becomes rather unreliable to look for specific combinations since they aren’t guaranteed.
Thanks @jhenderson, understood that we shouldn’t rely on consistent error codes.
While you’re thinking about the errors API, can I interest you in the possibility of exposing POSIX errnos? I posted a separate thread about that.
