Open yarikoptic opened 4 years ago
Thanks @yarikoptic. This sounds valuable. We'd have to think about what we want our Exception ontology to be.
Anyone want to offer some suggestions?
"ontology" -- ;-) Exception ontologies like a religion and might cause if not a war, then a stomach to rumble to start with.
I would recommend to review your favorite established libraries, and follow the suit. Overall, reusing standard exceptions https://docs.python.org/3/library/exceptions.html is a good strategy to follow, and HDMF largely already uses them. It is for those Exception's originally mentioned -- some could be replaced with standard ones or some more HDMF specific exceptions could be defined.
I think especially in the ObjectMapping it will be useful to have our own exception types to more clearly communicate where the exception is coming from. In other cases it will be useful to user more specific standard exception types (e.g, when we raise issues due to HDF5).
See https://github.com/NeurodataWithoutBorders/pynwb/issues/1144 for a need for a dedicated Exception class for missing namespaces.
Ideally many exceptions raised by HDMF should have some base classe(s) for exceptions of "HDMF nature". For some cases where it is indeed a typical IndexError (e.g. out of bounds like below), should be ok to raise it, but even then there could be
class HDMFIndexError(IndexError)
.Why am I here with this -- I just ran into:
and code indeed has a good number of those:
which makes it hard to impossible for outside code to really tell if it is something "core" (permission, IO, etc errors) spit out by standard libraries or something PyNWB or HDMF dislikes. It makes outside code to resort to just
except Exception
which IIRC even pep8 doesn't like ;-)