You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I like using selections (and everything else) in a pythonic fashion (i.e. if it looks like a dict it should mostly behave like one even if under the hood it's all HDF5). One strength of MDS is hiding all the bookkeeping.
Therefore, it is annoying if a non-existent, say, selection raises NoSuchNodeError (no idea what kind of exception this is) when I tried
try:
sel=self.sim.selections[name]
exceptKeyError:
# do something about it because selection 'name' is not stored in the sim
because from the syntax I expected to get a KeyError.
The text was updated successfully, but these errors were encountered:
Thanks for filing this issue. Raising exceptions at the level of the frontend (tags, categories, selections) that reflect what is failing at that level is one of the rough edges I hope we can smooth out sooner than later. As you noticed, many of these components raise exception at the level of PyTables, and they are not caught and re-raised in more meaningful ways.
Containers and their aggregators should be able to work with different
backends, which may very well not be PyTables files. To make this
possible, we need to catch PyTables-specific exceptions at the File
level, and raise more generic exceptions to be caught at the
Container/aggregator level.
We now follow the convention that backend-level exceptions that are
specific to the implementation of that backend need to be caught and
re-raised as either built-in exceptions or MDS exceptions. Containers
and aggregators must then catch and re-raise the appropriate
interface-level exception with an appropriate interface-level message.
For the changes made in this commit, these re-raises look a bit silly
since the messages and exceptions are identical to those caught. We
leave them in, however, to indicate the clear separation between backend
and frontend, and that these exceptions/messages may differ between the
two levels.
Added seleciton tests.
I like using selections (and everything else) in a pythonic fashion (i.e. if it looks like a dict it should mostly behave like one even if under the hood it's all HDF5). One strength of MDS is hiding all the bookkeeping.
Therefore, it is annoying if a non-existent, say, selection raises NoSuchNodeError (no idea what kind of exception this is) when I tried
because from the syntax I expected to get a KeyError.
The text was updated successfully, but these errors were encountered: