-
-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
To panic or not to panic when passing incorrect argument types? #845
Comments
A bit of background here: Godot has two calling conventions -- variant call (varcall) and pointer call (ptrcall). The former is fully dynamic and is used whenever you use reflection, e.g. If you look at the way how Godot defines those in the GDExtension API, you'll come across two signatures: typedef void (*GDExtensionInterfaceObjectMethodBindCall)(
GDExtensionMethodBindPtr p_method_bind,
GDExtensionObjectPtr p_instance,
const GDExtensionConstVariantPtr *p_args,
GDExtensionInt p_arg_count,
GDExtensionUninitializedVariantPtr r_ret,
GDExtensionCallError *r_error
);
typedef void (*GDExtensionInterfaceObjectMethodBindPtrcall)(
GDExtensionMethodBindPtr p_method_bind,
GDExtensionObjectPtr p_instance,
const GDExtensionConstTypePtr *p_args,
GDExtensionTypePtr r_ret
); The varcall function pointer offers an output parameter Godot cannot propagate errors in ptrcalls. This is a limitation of the engine, and the reason why godot-rust can currently not let GDScript abort in such cases. Maybe there is a way -- in case you discover one, I'd be interested to hear! |
Try the
You can try this, but I'm not sure how many things break in the library, as it's not designed for it. So use at your own risk. |
After some discussion with the GDExtension team, it seems like the varcall error handling capability is not intended for domain-specific errors (such as Rust panics), but rather type and arity checking of the arguments. If we handle Rust panics purely in Rust code and don't tap into the varcall error mechanism, we may be able to make the experience more consistent with ptrcalls. Closely related: #105 (comment) |
A bit off-topic here but I want to note somewhere that |
I think this would be useful to mention in a new separate issue. It's not really related to this issue at all. We havent really prioritized binary size very much and we dont even have an issue tracking it specifically, so getting some more conversation started about it would help gauge interest and see how it should be prioritized. |
An example function:
These calls don't panic and abort the script instead:
But these ones panic and do not abort the script (
null
is returned instead):I don't know which behavior is correct (but according to API design principles (which contains a broken link btw) and #327 (comment), I assume you are a fan of panics)
But regardless, I expect consistent behavior: panic everywhere or don't panic at all.
(In general, I'd prefer not to panic because I'm trying to compile with
panic = "abort"
in hopes of reducing binary size, godot-rust binaries are so damn huge...)(or maybe explicitly disallow
panic = "abort"
somewhere in the "Getting Started" chapter of the book if you think this sucks)The text was updated successfully, but these errors were encountered: