search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.99k stars 21.16k forks source link

[TRACKER] Error macros with cryptic messages due to not having proper custom messages defined #42719

Open Calinou opened 4 years ago

Calinou commented 4 years ago

If you stumble upon difficult-to-understand error messages (regardless of your skill level with Godot), please report them here. In your comment, make sure to state:

Note that this issue isn't about reporting bugs, but reporting cryptic error messages. This issue is about improving error messages so users can figure things out by themselves more easily. If you stumble upon a bug, please open a dedicated issue instead of commenting in this tracker issue.

See https://github.com/godotengine/godot/issues/24199 for background.

Issues

For contributors

Even if you're a beginner in C++, you should be able to add error macros. This is why this issue has a junior job label :slightly_smiling_face:

To add error explanations to existing errors, search for their origin in the source code (by reading the automatically-generated error message), suffix the error macro with _MSG and add a parameter with a custom message at the end.

We recommend adding context (such as provided arguments versus expected ones) whenever possible. Some examples:

# Best, do this whenever possible:
"Can't listen server on port 420000. The port number must be between 1 and 65535."

# OK:
"Can't listen server on port 420000."

# Bad, this doesn't give much context:
"Can't listen server."

Here are some real-world examples of improving error explanations: https://github.com/godotengine/godot/pull/41352/files, https://github.com/godotengine/godot/pull/35862/files

See Error macros in the documentation for more information.

Calinou commented 1 month ago

Ran an OS.execute() command, probably with some wrong arguments. Hard to tell from this message! Turns out I was actually looking for OS.shell_open(). If this error is specifically for trying to execute a non-executable file, pointing to this function as an alternative in the error message might be useful.

The error message was improved in 4.x. I just backported it to 3.x: https://github.com/godotengine/godot/pull/97171

Note that no error message is present on Linux (and possibly macOS) when running unknown commands on both 4.x and 3.x currently. We should aim to fix that for consistency.

Attempted to execute Godot through the command line, while opening a specific scene. Guess the scene path was wrong, or something like that.

load_default_certificates() is a method that is meant to be called only once per engine session: https://github.com/godotengine/godot/blob/694d3c2930bdfb43fd93e1e6641f66c4f19a5c77/modules/mbedtls/crypto_mbedtls.cpp#L360-L364

main.cpp calls load_default_certificates() twice, but in mutually exclusive conditions. This means it should never be called twice in a single session in practice. This hints at a bug somewhere in the main.cpp logic when using an invalid scene path (which has been known to cause some variables in that file to go haywire).

The Object was deleted while awaiting a callback message should really be a warning or error, and could use more information on what the 'object' and the 'callback' are/were. Right now the only way to figure out what caused this is by looking at every Container in the entire project.

For context, this was originally a warning, but it's always been commented out:

image

However, we can't use Godot's error/warning system here to avoid infinite recursion, so we'll need to manually replicate the error/warning formatting using ANSI escape codes (which is feasible, but slightly tedious).

I'm not sure if we can call the Object's _to_string() method here as it's already been deleted when the message is printed. We might be able to print something about the callback, but that's about it.

SpockBauru commented 1 month ago

Got this while messing with visibility range (begin/end margin and fade) of several objects scattered across the map:

E 0:00:11:0729   texture_create: Too many mipmaps requested for texture format and dimensions (5), maximum allowed: (4).
  <C++ Error>    Condition "required_mipmaps < format.mipmaps" is true. Returning: RID()
  <C++ Source>   servers/rendering/rendering_device.cpp:712 @ texture_create()

image

Which texture? The name would help greatly. If possible, the faulty mesh and world position would also help, but just the name of the texture would help by a lot.

AThousandShips commented 1 month ago

This is a known limitation, the rendering server doesn't know the texture file or anything else like that (nor is it guaranteed to even be known), see: