Guidance for GDExtension Languages

[Splizard]

I'm the author and maintainer of graphics.gd, a project that enables GDExtensions to be written in Go. I'm currently integrating sentry-godot with one of my graphics.gd projects. Whilst sentry-godot is suitable for catching Godot errors and crashes, it would be great to inject Go information alongside it.

My current approach is to add sentry-go so that Go panics can be captured too, the only issue being, the context that sentry-godot captures versus sentry-go is no longer correlated (with entirely different context) ideally they could be combined somehow.

Hoping the sentry team can provide some guidance on the best way for community GDExtension Languages (Rust/Swift/Go etc.) to integrate alongside sentry-godot. Should there be APIs for feeding in stack traces from different languages for example? I've had users run into trouble with debuggability of Godot + Go and I think sentry could be a good solution here.

[linear-code]

GODOT-219

[limbonaut]

Thanks for reaching out @Splizard! Exposing a stack trace context API is a fairly sizable feature, so we can't promise a timeline at this point. It would still only work as long as the errors are non-terminal and no memory corruption has occurred.

If we’re talking about unrecoverable errors, you probably want to stick with sentry-go anyway. This avoids going through Godot bindings and touching potentially corrupted runtime. Scope synchronization with sentry-godot could be done by exposing something like a scope observers interface. It’s not fully fleshed out yet and isn’t exposed in the API, but it’s something we could support in a future release.

For a more interesting alternative, if you fully implement ScriptLanguage interface (particularly its debug methods), it should be possible to walk the stack trace and pass the data via Godot’s script backtrace mechanism. This would probably work only if you recover after such panics. Enabling this on the sentry-godot side would need a small amount of work, but it would benefit any language extension implementing ScriptLanguage. I’m not 100% sure this part of ScriptLanguage is currently exposed. If it isn’t, that would be a strong argument for advocating its exposure.