0 votes

Basically any error makes the application crash when it's exported in a non-debug version. While it's totally clear that we should make the game as much error-less as possible, doesn't this behavior contradict the engine philosophy presented by Juan here and here?

Here's a really simple example of intentionally bad code that results in a crash:
crashity crash

This is Godot 3.1 in its stable version with up-to-date export templates.

in Engine by (20 points)
edited by

1 Answer

0 votes

I think it should be the developer's job to do a null test of a result. ;)

by (85 points)

Well, sure, I too dream of an ideal world where developers anticipate every scenario and write 100% errorproof code. ;)
Realistically though, it's still highly possible, given that game projects tend to be quite large in scale, to have some scenarios uncovered, like when using yields extensively and irensponsibly. And I remember Juan talking multiple times about letting programmers to write "quick and dirty" code.
So the question is more about divergence in what the main engine dev says and how the engine actually work.

I think I know what you mean. It's always a compromise between overhead and performance. Checking data and variables in the normal running scope is one thing - another thing to do with dynamic objects. I'm not even talking about multithreading here. Coding "Quick and dirty" sometimes just means being able to write code quickly - but not all time safe.

Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read How to use this Q&A? before posting your first questions.
Social login is currently unavailable. If you've previously logged in with a Facebook or GitHub account, use the I forgot my password link in the login box to set a password for your account. If you still can't access your account, send an email to webmaster@godotengine.org with your username.