Catch other exceptions from readDataset to handle file open failures

[akshitamav]

readDataset throws (from HDF5) many exceptions that inherit from H5::Exception.
These exceptions should be handled and printed as a failure to open the dataset, so BAG can exit gracefully.

[selimnairb]

@akshitamav Sorry it took me so long to get to this. Your branch inherited temporarily broken Python tests that we in the master branch, so the tests aren't currently passing. This has since been fixed in the master branch. Can you merge the latest OpenNavigationSurface:master into your branch and re-push? Thanks!

[selimnairb]

@akshitamav Sorry it took me so long to get to this. Your branch inherited temporarily broken Python tests that we in the master branch, so the tests aren't currently passing. This has since been fixed in the master branch. Can you merge the latest OpenNavigationSurface:master into your branch and re-push? Thanks!

@akshitamav Can you merge the latest OpenNavigationSurface:master into your branch and re-push?

[akshitamav]

I have updated my branch, I think it should be right now

[akshitamav]

I'm not really sure why this is failing here

[selimnairb]

I'm not really sure why this is failing here

The Test Reporting fails currently for pull requests since they run with read-only credentials. I thought I had fixed this last week to skip the parts that would publish the results (which requires write credentials), but apparently it needs more work. We can ignore for now.

[selimnairb]

@akshitamav Do you want to resolve the issue you identified here in this PR?

[akshitamav]

Sure! I'm working on that right now. I'm not sure I can make it work the same way on windows (microsoft makes it work differently there) but I'm going to make it so that it also calls the "old" signal handler too so that it doesn't break other libraries signal handlers. Do we need it to work on windows as well?

[akshitamav]

I added my code so far into the branch now @selimnairb, but I need to do some more testing to make sure it works. It lets people set cleanup functions, and also calls any handlers that were already set before exiting so it doesn't interfere with other libraries

[selimnairb]

I added my code so far into the branch now @selimnairb, but I need to do some more testing to make sure it works. It lets people set cleanup functions, and also calls any handlers that were already set before exiting so it doesn't interfere with other libraries

@akshitamav This looks like an interesting start and would cover opening BAG files using the C API (which is in the code, but not well tested currently; the preference is for people to use the C++ API). I think we would also need to add this to bagCreateFromFile, bagCreateFromBuffer. Is it necessary to have BagAbortHook in bagFileClose? My naive guess would be that BagAbortHook should be setup once (so maybe BagAbortHook needs to be a singleton?), the first time the BAG library is called, which would primarily be on opening or creating a BAG file. However, I may be mistaken.

Also, do we need to add BagAbortHook instances to BAG::Dataset::open, BAG::Dataset::create, and BAG::Metadata::loadFromFile, which are common entry-point's into the BAG library from C++ code.

[akshitamav]

Ah, yeah, we should add more construction of them. I actually made it so that it unsets itself when it destructs specifically so that code that isn't bag doesn't get affected by it. It is like "take out what you take in" for camping, so someone shouldn't get the bag handler run when their other unrelated code is running.

When it returns from BAG code, it restores the original signal handlers.

I need to add it to more places to be thorough, but we should probably only add it to places where HDF5 or libxml code can run so that it isn't being used more than it needs to be.