Don't abort, please?

[smurfix]

gdb complained:

#4  0x00007ffff7f9a00a in nanobind::detail::fail
    (fmt=0x7ffff7fa6d18 "nanobind::detail::nb_type_new(\"%s\"): base type \"%s\" not known to nanobind!") at /usr/share/nanobind/src/common.cpp:79

Ugh. That's a usage error in the Python script (importing those modules in the wrong order).
Could nanobind please throw an exception instead of aborting?

[oremanj]

If your modules depend on being imported in a certain order, then they should enforce that order by importing what they need.

[smurfix]

I'm loading user scripts. If the user doesn't know about these dependencies (or ignored them …) I'd like to give them at least a somewhat-reasonable error message. Crashing doesn't help here; a program started via GUI or a browser doesn't show stderr.

[oremanj]

The user should not need to know about these dependencies. You, the author of the extension modules, know about them. So, if sub depends on base, you can implement that by having the binding code for sub perform a nb::module_::import_("base"); before it extends the types from base.

Requiring the user to manage import order is not a viable solution, because there exist many tools that assume imports can be ordered arbitrarily for stylistic reasons. nanobind therefore treats this sort of issue as a programming error (abort) rather than an error in user code (throw an exception).

[smurfix]

The user should not need to know about these dependencies. You, the author of the extension modules, know about them.

I do see your point; however, that boundary isn't always as clear-cut as we might like it to be.

[wjakob]

There are good technical reasons to abort here. Nanobind extension code is often a very, very, very long sequence of class and function binding declarations. Imagine that these could fail and raise an exception. The compiler will have to add exception handling trampolines for every line of code that cleans up all the things constructed before, just in the remote possibility that something goes wrong. These are just trampolines and don't have any runtime cost in practice. But this is code that has to be stored somewhere, and it significantly increases the size of the generated shared librariy. For this reason, nanobind treats some types of errors comparably strictly and aborts. If a binding cannot be created, this means that something went very badly wrong, and it's the developers job to make sure that this cannot happen.