Asserts should not make the function return

[truanleiker]

Currently, assert() generates an error when failed. While not stated in the documentation, this causes the currently executing function to return null at the assert which creates two issues:

1. Code cannot be written after the assert which may prevent the programmer from implementing error handling code when the program enters an unexpected state.
2. It changes the program's behavior between debug and release builds since any code after the assert will not be executed in debug builds but will be executed in release builds, potentially resulting in uncaught bugs occurring in only the release build.

This makes assert() unsuitable for its intended purpose: catching unexpected states during debugging without altering runtime logic. The current workarounds are as follows:

• Use push_warning(). This logs a warning without returning from the function, but it does not halt execution in the debugging environment.
• Use push_error(). This logs an error and halts execution, and it is consistent between debug and release builds, but it still returns from the function.
• Use push_warning() combined with breakpoint. This achieves the desired effect, but having to write two lines each time you want this effect is not ideal.
• Place assert() in a wrapper function. This also achieves the desired effect by only returning in the wrapper function, but the programmer should not have to define their own function.

My proposal is to make assert() behave similarly to combining push_warning() and breakpoint.

[Calinou]

• Related to assert() should evaluate its arguments in release, and then no-op #502.

Use push_error(). This logs an error and halts execution, and it is consistent between debug and release builds, but it still returns from the function.

push_error() only prints an error – it doesn't halt execution when running from the editor.

[dalexeev]

In my opinion, your expectations in this case are not in line with the generally accepted standards. As far as I know and can judge from the Wikipedia article, in most languages, failure to meet the assert condition results in a program crash or an exception being thrown (which results in the function exiting, unless the assert is wrapped in a try-catch or similar construct). This has rationales:

Then, if it is not in fact true – an assertion failure – the program considers itself to be broken and typically deliberately crashes or throws an assertion failure exception.

Many assertion implementations will also halt the program's execution: this is useful, since if the program continued to run after an assertion violation occurred, it might corrupt its state and make the cause of the problem more difficult to locate.

Assertions are distinct from routine error-handling. Assertions document logically impossible situations and discover programming errors: if the impossible occurs, then something fundamental is clearly wrong with the program. This is distinct from error handling: most error conditions are possible, although some may be extremely unlikely to occur in practice. Using assertions as a general-purpose error handling mechanism is unwise: assertions do not allow for recovery from errors; an assertion failure will normally halt the program's execution abruptly; and assertions are often disabled in production code. Assertions also do not display a user-friendly error message.

I think it is perfectly fine to create a custom error checking method if none of the built-in methods suit your needs. Note, however, that assert has the advantage of not being executed in release builds. Whereas a custom method will have a small overhead even if it does nothing in release builds.

[truanleiker]

You are correct that the classical idea of a failed assert crashes the program or throws an exception. However, other languages do this out of necessity as that is the only way for them to halt execution since they are designed to be independent from a debugger. GDScript, on the other hand, is ran in an engine with an integrated debugger that is capable of halting execution without outright crashing the program. In addition, asserts in GDScript already diverge from the classical behavior by simply exiting the function instead of crashing the program, thus we shouldn't worry too much about adhering to standard conventions in this case.

My main issue is that GDScript does not provide a feature that accomplishes the following:

1. Halts execution upon a failed assertion while debugging
2. Logs the failed assertion
3. Maintains consistent behavior between debug and release builds
4. Is compiled out of release builds for optimization purposes

By modifying assert so that it doesn't exit the function, programmers can then combine error handling with assertions so that their code can be robust while also making it obvious when and where something has gone wrong.