It can be a real pain to correctly maintain the error messages where you pass in the function names. I'm not too worried if there is an one-off need to do it just in this case, but if this is a pattern we will continue to need maybe we can file a story to investigate alternatives?

@jp-dark quite the contrary! This is methodical and intentional for the very sake of maintainability.

• Details of error-message content are computed in libtiledbsoma -- to avoid code duplication between Python and R
• The function name must be the one the user invoked -- at the user level
• Passing in the function name ensures that we are not hard-coding within libtiledbsoma what we thinik the user-facing function name is, but rather, letting the Python/R layers have control over the names.

I very much do not want to lose the ability to flow user-level names (what they actually typed) down to exceptions thrown at lower levels.

It's a long-standing curse that a user sees a cryptic exception and can't map it to what they typed. Propagating a user-level function name is important for that, and if anything, we should do this more often, not less.

If your concern is double entry at the Python/R-level callsites, maybe we can use something like

import inspect
function_name_for_messages = inspect.currentframe().f_code.co_name

?

If your concern is double entry at the Python/R-level callsites, maybe we can use something like

import inspect
function_name_for_messages = inspect.currentframe().f_code.co_name

Yes - this. I worked with a large Fortran codebase that required the developer to add the function name to the error messages and it led to a lot of incorrect error messages due to a combo of copy/paste errors and forgetting to update message string when a function name change occurred. So long as we are automatically getting the function names from Python/R, I'm all for propagating this pattern.

@jp-dark awesome!!! :)

For reference, the R analog:

  function_name_for_messages <- sys.call(sys.parent(n=1)[[1]]