Summary
Currently, it seems that h5 throws std::runtime_error when things go wrong. It would be nice to have a custom and documented h5::exception type thrown instead that wraps the HDF5 error handling API, exposing the type of error and what went wrong programmatically.
Motivation
Sometimes errors during reading an HDF5 file are not fatal and can be recovered from by the caller. However, it is hard to do cleanly with a std::runtime_error. A specific HDF5 exception would allow to distinguish if there is a typo in the destination path or something fatal has happened and the file is inaccessible.
The specific use case I had was reading an attribute. The API does not yet expose a way to check if an attribute exists, so catching an exception seems to be the only way to handle missing attributes.
Implementation
A simple exception type carrying the HDF5 error code, a message and maybe a representation of the error stack.
Summary
Currently, it seems that h5 throws std::runtime_error when things go wrong. It would be nice to have a custom and documented h5::exception type thrown instead that wraps the HDF5 error handling API, exposing the type of error and what went wrong programmatically.
Motivation
Sometimes errors during reading an HDF5 file are not fatal and can be recovered from by the caller. However, it is hard to do cleanly with a std::runtime_error. A specific HDF5 exception would allow to distinguish if there is a typo in the destination path or something fatal has happened and the file is inaccessible.
The specific use case I had was reading an attribute. The API does not yet expose a way to check if an attribute exists, so catching an exception seems to be the only way to handle missing attributes.
Implementation
A simple exception type carrying the HDF5 error code, a message and maybe a representation of the error stack.