Skip to content
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

Add GDScript warning pages #10635

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from
34 changes: 23 additions & 11 deletions tutorials/scripting/gdscript/warnings/ASSERT_ALWAYS_FALSE.rst
Original file line number Diff line number Diff line change
Expand Up @@ -10,27 +10,39 @@ The warning message is:
When this warning occurs
------------------------

The :ref:`assert() <class_@GDScript_method_assert>` keyword can be used to ensure that a given condition is met before allowing code execution to continue. If the first argument passed to it evaluates to ``true``, the rest of the function will run as expected; if it is ``false``, then the project will stop.
The :ref:`assert() <class_@GDScript_method_assert>` keyword can be used to ensure that a given condition is met before allowing code execution to continue. If the first argument passed to it is truthy, the rest of the function will run as expected; if it is falsy, then the project will stop.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice if we defined truthy/falsy somewhere else in the GDScript docs that we could link to, see also #4408

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. In general I'm nervous about even using the terms "truthy" and "falsy" right now, because neither of them currently appear in the docs at all from what I can see (searching either of them on the online docs turns up no results).


If ``assert()`` is passed an expression that is guaranteed to be ``false``, then the ``assert()`` call will always stop the project.
If ``assert()`` is passed something guaranteed to be falsy, then the ``assert()`` call will always stop the project.

.. code-block::

# The boolean false will always be false, so this assert will always stop
# the program.
assert(false, "False is false")
# Zero always evaluates to false.
assert(0, "Zero is falsy")

# Likewise, 5 will never be 6, so this assert will always stop the program.
assert(5 == 6, "5 isn't equal to 6")
# Likewise, an empty string always evaluates to false.
assert("", "An empty string is falsy")

# This line of code won't be executed in debug builds because the editor
# will have stopped at the assert calls above.
print("Hello, world!")
.. note::

Godot will *not* raise this warning if a literal falsy boolean is passed:

.. code-block::

# Despite false being passed, this won't raise ASSERT_ALWAYS_FALSE.
assert(false, "False is false")

# This evaluates to a boolean which is false, so it also won't raise
# the warning.
assert(3 == 4, "3 isn't equal to 4")

This is because ``assert(false)`` calls are often used in development to forcibly halt program execution and avoid strange errors later on.

See `issue #58087 <https://github.com/godotengine/godot/issues/58087>`_ for more information.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
See `issue #58087 <https://github.com/godotengine/godot/issues/58087>`_ for more information.
See `GH-58087 <https://github.com/godotengine/godot/issues/58087>`_ for more information.

Usually it's styled like this.

Linking to the original issue/PR from the docs seems like an antipattern though, usually we would rewrite the relevant content of the issue/PR into a form suitable for the manual. I'm not wholly against linking though

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of linking the issue/PR, similar to how one might paraphrase a primary source in an essay and then provide a citation to the primary source itself, so the reader can look at it themselves if they so wish. But the reasoning provided in the issue might be general enough that it doesn't "need" a citation, and it could also make it unclear when it's appropriate to link to GitHub, resulting in the docs becoming more cluttered.


How to fix this warning
-----------------------

Assuming you want code following the ``assert()`` to run, remove it from your code. If you do want code execution to stop at that point, :ref:`consider using breakpoints instead <doc_debugger_tools_and_options>`.
Assuming you want code following the ``assert()`` to run, remove it from your code. If you do want code execution to stop at that point, replace the condition with ``false``, or :ref:`consider using breakpoints instead <doc_debugger_tools_and_options>`.