It's not necessarily causal that this triggered on https://github.com/jdblischak/centralized-tiledb-nightlies/issues/21. It's true that the apis/python/tests/test_shape.py was recently introduced on the #2407 stack. However, whether un-rethrown errors (on implicit pybind body, as in the "before" parts of this PR) reach the Python level as tiledbsoma.SOMAError or RuntimeError or tiledb.cc.TileDBError has some element of randomness.
However, @nguyenv and I have long found that some things come through as RuntimeError on one machine, and tiledb.cc.TileDBError in another. We suspect that TileDB-Py's exception registrar has a race condition with our own.
Regardless, a safe practice is explicit catch-and-rethrow at the boundary between C++ and Python, which is what we do more of here.
Issue and/or context: Resolves #2961
Changes:
Do explicit try-catch. See also #783.
Notes for Reviewer:
It's not necessarily causal that this triggered on https://github.com/jdblischak/centralized-tiledb-nightlies/issues/21. It's true that the
apis/python/tests/test_shape.py
was recently introduced on the #2407 stack. However, whether un-rethrown errors (on implicit pybind body, as in the "before" parts of this PR) reach the Python level astiledbsoma.SOMAError
orRuntimeError
ortiledb.cc.TileDBError
has some element of randomness.There's an attempt to globally register a rethrow: https://github.com/single-cell-data/TileDB-SOMA/blob/1.13.1/apis/python/src/tiledbsoma/pytiledbsoma.cc#L36-L50
However, @nguyenv and I have long found that some things come through as
RuntimeError
on one machine, andtiledb.cc.TileDBError
in another. We suspect that TileDB-Py's exception registrar has a race condition with our own.Regardless, a safe practice is explicit catch-and-rethrow at the boundary between C++ and Python, which is what we do more of here.