Hi @oremanj,

I agree that the code here is not as solid as it should be, and that this will require fixes in the future.

This will involve adapting the logic to avoid the possibility of an exception being raised in a noexcept block. I want to keep the casters exception-free and keep the noexcept attribute on the from_python function.

The reasoning is as follows

• Casting failures can frequently happen while trying out overloads. Raising exceptions in C++ expensive in terms of runtime performance (usually considerably higher than an equivalent exception in Python).
• There is also a noticeable code size impact since the C++ compiler must create data structures to facilitate unwinding the stack.
• The casters are components that are usually instantiated many times. I prefer to localize all complexity related casting failures there instead of dumping this complexity on the C++ exception/unwind system.

Therefore, the casters should return false when the conversion fails, instead of raising an exception. In the case of nested casters, the way in which they are combined may need further adaptation. For example by using nb::try_cast instead of nb::cast.

Does that make sense?

Your reasoning for not wanting to catch exceptions within from_python makes sense to me.

For example by using nb::try_cast instead of nb::cast.

This isn't really better though; nb::try_cast also puts a try/catch around its call to the cast operator (by which I mean caster.operator cast_t<T>()).

The basic problem is that there are certain types of failures that can't be noticed until the cast operator executes (because they depend on the exact casted-to type, etc), and the only way it has to signal those failures is raising an exception. So if we want to avoid catching exceptions in casters (or nb::try_cast for that matter), we're going to need a different way to signal those failures. What do you think of my second bullet - "add a member function template to the type caster interface that checks whether conversion to T will throw, and require each 'wrapper' caster to check it before calling the cast operator"? In practical terms, that might look like a type_caster method

template <typename T>
bool cast_op_will_succeed() const;

which can be defined as static constexpr bool cast_op_will_succeed() { return true; } for almost all casters, and would need to be implemented specially for the fallible-cast ones (the base caster, char, and unique_ptr) and for those that delegate to other casters' cast operators within their own cast operator (pair and tuple). Then in cases where we don't want to catch exceptions, we can check caster.template cast_op_will_succeed<T>() before calling caster.operator cast_t<T>().

AFAIK the main failure case of try_cast involving an exception occurs when attempting to cast None into Class& for a class binding Class. I think it's an ugly corner case and would be nicer to resolve without exceptions.

The cast_op_will_succeed sounds like a good solution. Are you interested in implementing this as a PR? If so, a super-minor preference would be to give it a shorter name, e.g. can_cast<T>

Yes, I'll take a shot at implementing this, though likely not for a week or two. Thanks for confirming I wasn't missing something!

Any news on this? @oremanj ?

I will hopefully have some time to work on this tomorrow!