debugging OCCT errors

very often I'm finding that operations that work for some shapes fail when called on other shapes, so to get the result I want I'm trying to create the same shape or similar shapes in different ways until the command works. This is extremely frustrating and time consuming since the only feedback is `OCP.StdFail.StdFail_NotDone: BRep_API: command not done`.

Is there any way to obtain more information about what caused the failure, and perhaps since cadquery also controls the native bindings, perhaps there could be a way to trace what calls are made to OCCT and with which data so that problems can be examined in isolation (although if the API is stateful like cadquery then perhaps this wouldn't be useful)?

Is there a way to dump and load back in wrapped OCCT objects? For one of these instances where an operation failed I tried:
- exporting the offending geometry to STEP and reading them back in but something about the edges was not preserved during the export. The original edges were closed but after importing they were not so I could not perform the operation on them.
- the `DumpJson` method of `ToposDS_Edge` at least but I don't think it's wrapped properly because it requires a `std::ostream` which can't be constructed from python.
- exporting to XML/CAF but there doesn't seem to be a way for cadquery to import these files
- pickling on the off-chance that was implemented but that failed as well.