Exceptions: need cleanup

[gicmo]

In quite a few places (~80) we use std::runtime_error. We should find more specific errors so clients can react more specifically if they want.

[stoewer]

Agreed. Maybe we should collect a list of different error types here in this issue discussion?

[gicmo]

@stoewer Yes that would be a good idea.

[gicmo]

List is down to ~60.

[gicmo]

While working on issue #462 I discovered what we have quite a few very specific exception classes, like IncompatibleDimensions, UnsortedTicks that are used only in one or two places and might just be general std::invalid_argument exceptions with the appropriate error text. Same goes for EmptyString, DuplicateName and InvalidName which could all be InvalidName or InvalidIdentifier (or again just std::invalid_argument).

Additionally MissingAttr is thrown in cases when a file is invalid, e.g. a RangeDimension without tick attribute is present. I am thinking that throwing a exception into the API users face is maybe not the right thing todo here, but just recover as good as it is possible (empty array of ticks) and leave the rest to the file validation API.

[jgrewe]

I'm not sure about the exceptions. The "fine-grained" exception classes allow us to provide more or less meaningful messages on the nixpy side once the exceptions, for whatever reason, loose their message as was reported by Ajay some time ago. On the other hand I agree with the desire to reduce the amount of different types.

[gicmo]

@jgrewe That exception messages were lost is very likely due to bug #462 (I have added some more detailed what was going on). We should check if the messages are indeed not empty anymore with this fix.

[jgrewe]

@gicmo Ah, cool, makes sense. I will check this on the python side. We could then simplify the exceptions on the nix side and also clean up the exception wrapper.

[jgrewe]

I will clean this up and also replace the runtime-errors.

[jgrewe]

TODO

• replace runtime errors with proper exceptions
• separate into logic_errors and _runtime_error, i.e. those in which the user violated the program logic and could do better and those that are hard to predict from the program's point of view
• remove where in exceptions and replace with an option of get a backtrace
• error handling in the front-end objects, where applicable e.g. check for name constraints, etc.

[jgrewe]

In several entities (e.g. Block) we require certain information to be non-empty, unique and what not. During the file_backend implementationf I noticed that the checks are not consistent, complete or even rely on throwing hdf5 exceptions. In fact we could and, imho, should, do all these checks on the front-end entities. Opinions on this?