Avoid panics in general

[dalcde]

They are pretty annoying when using python bindings because it terminates the whole python session

[dalcde]

I also propose that we introduce our own error type that captures backtrace information. We can then implement From<E> for OurOwnError where E : std::error::Error + Send + Sync + 'static. To do actually do this, OurOwnError cannot implement Error. We can mitigate this by implementing From<OurOwnError> for Box<dyn std::error::Error>.

[hoodmane]

A large number of panics are generated by library calls (i.e., index errors) and stuff like that.
I think the right approach is to add code in the python bindings to ask permission before calling the underlying code.

With this load json method, it's a good idea to return a result because the invariants on the json are complicated and there was previously no way to tell if the file was valid without doing the entire load json function. But many of our methods have simple invariants that can be verified in the wrappers.

[dalcde]

I agree that a lot of panics are difficult to avoid, since they may leave our object in invalid states. My general philosophy is that we should not panic because the user made a typo/some error; only if there is some coding error. For example, in my python bindings, I always call algebra.compute_basis before doing anything (this should probably be done in the rust code as well; we are not very consistent about this).

[hoodmane]

I think it is only acceptable to automatically call algebra.compute_basis() in functions that are expected to do actual work. In lookup functions, the correct behavior is to throw an error asking the user to call compute_basis first. That way, it is clear which functions are doing work and which calls are not.

[dalcde]

Yeah we can either check or compute. I guess we should be careful when something can potentially take forever/use up a lot of memory.

[hoodmane]

I think the python interface should not panic under any circumstances. If something really bad happens and we destroy a bunch of stuff, we can free the objects and report back a "critical" error. Latter attempts to access the destroyed objects from python should return a reference error.

Destroying everything associated to one resolution is fine. There might be other unrelated stuff in the same python instance, so panicking is not fine.

I don't think we need to worry about this too much because panics are so annoying that we will feel motivated to clean them up as they arise.

[hoodmane]

Once the python front end is stable enough, we should hunt for any remaining panics.

[dalcde]

On Fri, Mar 20, 2020 at 01:37:02PM -0700, Hood Chatham wrote: I think the python interface should not panic under any circumstances. If something really bad happens and we destroy a bunch of stuff, we can free the objects and report back a "critical" error. Latter attempts to access the destroyed objects from python should return a reference error. Destroying everything associated to one resolution is fine. There might be other unrelated stuff in the same python instance, so panicking is not fine.

I agree. A lot of things like the module definitions are probably still usable. If something is panic-prone and difficult to fix we can catch panics and destroy objects appropriately when needed.

I don't think we need to worry about this too much because panics are so annoying that we will feel motivated to clean them up as they arise.

Hence this thread