More robust error system for GDScript

[atirut-w]

This is really bothering me as someone who occasionally write singleton API stuff in Godot.

As of currently, there are no way to throw errors and the most you can do is pushing error messages to the log, nothing more. The code does not stop execution and the only way for the caller to be able to acknowledge and do something with errors is to use signals, which works but is an annoying workaround.

Most programming languages(C#, Python, Lua, etc.) have a complete error system where you can throw errors, and they will:

• Crash the program if there is nothing to handle the error
• The error gets handled by the engine
• It gets caught manually(try-catch, pcall & xpcall, etc.)

I know this addition will require changing a lot of the engine API and can only be implemented in 4 (since this may be a breaking change) but it should still greatly help with making API interfaces in GDScript where throwing error is a very useful thing.

[miv391]

Could you show what kind error handling code you are currently writing and what kind of code you would like to write?

[atirut-w]

As of currently there are no way to let calling functions know about errors occuring other than to set up an error signal so none. You literally can't handle errors the traditional way with GDScript.

Sorry my brain tripped

[atirut-w]

Something similar to Python's try-except block could work since GDScript is already kind of Pythonic

[zinnschlag]

I agree with your position, even though I haven't considered using signals for error handling (sounds kinda awkward).

What I am doing right now with my error handling is to log (and assert) and hope for the best. Kinda unnerving. That is certainly not what writing robust code looks like.

Unfortunately the chances for such a change are about 0. GDScript wouldn't just need exception support. It would also need support for writing exception-safe code. And it would have to be done going from 3.x to 4.0, not 4.x. We certainly don't want more API breaking going from 4.0 to 4.1. Since we are already on the 3rd alpha for 4.0 time is running out on that.

Additionally at leat a part of the core teams seems to be kinda hostile to exceptions (other than some third-party code and some C# stuff the Godot code base doesn't seem to use a single exception).

And then there is this statement from the official documentation:

Why does Godot not use exceptions?

We believe games should not crash, no matter what. If an unexpected situation happens, Godot will print an error (which can be traced even to script), but then it will try to recover as gracefully as possible and keep going.

Who ever wrote that clearly doesn't understand exceptions, since it is the other way around. Using exceptions properly allows you to recover from errors far more easily and more reliably than other methods.

[zinnschlag]

increase binary size significantly in C++

Depends on your definition of significantly. But yeah, by Godot standards that is a reasonable argument.

This is because exceptions are known to cause performance issues

That's just a myth. Most C++ implementations use a zero-cost approach (except for the bloody 32-bit Windows implementation, which should be irrelevant by now). Generally exceptions should be marginally faster in many cases (because you often need less error handling code in the non-exception situation).

The only exception (no pun intended) is when an exception is actually thrown. But that is supposed to be an exceptional situation (okay, this time the pun was intended) and certainly when people encounter a defect or some other problem that interrupts normal operation they will have other things to worry about than a momentary performance drop.

[mhilbrunner]

Source?

Mostly any gamedev book, engine or middleware. Since C++11, you can mark functions that don't use exceptions to avoid the overhead, but basically nobody does. Everyone in gamedev just collectively avoids exceptions, for better or worse. UE4 doesn't ship with exceptions enabled either. AFAIK exceptions are also even worse on Console, on x86 (which may be an issue for us) and on/for Windows when compiling with anything other than MSVC due to patents (which definitely is an issue for us).

Also:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html
https://pspdfkit.com/blog/2020/performance-overhead-of-exceptions-in-cpp/

(except for the bloody 32-bit Windows implementation, which should be irrelevant by now)

We're AFAIK currently supporting this platform.

With that said, I see a slight trend towards revisiting this, i.e. afaik Vulkan has exceptions enabled by default?

[zinnschlag]

We're AFAIK currently supporting this platform [32 bit Windows]

Wasn't aware. Is that actually still in use? AFAIR there hasn't been a 32-bit only CPU in about 20 years.

Would love to see some numbers. Unfortunately the Godot community poll distinguishes only by platform and not by bitness.

Mostly any gamedev book, engine or middleware

Which were most likely written by people working with 32-bit Windows. Or more recently, people that had been learning from such books/engines/people and were just parroting this statement, even though it has been largely irrelevant for a while now.

[atirut-w]

AFAIR there hasn't been a 32-bit only CPU in about 20 years.

Think of the poor people that have to use old 32 bit processors 😔

[zinnschlag]

Would have expected that most of these very old CPUs have died by now. But can't rule it out. Maybe other people have more luck with their hardware than I. As I said, would love to see some numbers.

Anyway, we are getting off topic. If GDScript were to implement exceptions surely it could go for a zero-cost implementation and that would work just as fine on 32 bit Windows.

[miv391]

I don't like using exceptions for error handling. Maybe I have seen too much code where error handling using exceptions is just wrapping try-catch around code and ignoring the error. Exceptions have their use, but I think there are better alternatives for error handling. Maybe GDScript could have Go-like error handling, athough it would need some big changes too. Functions should be able to return multiple return values. A new type, error, would be needed. Function would return the error as a last return value. The caller should then always check if error was returned. Code would look something like this:

func do_something(a: int) -> int, error:
    if a < 100:
        return a + 1, null  # maybe return null by default, if second return value is not given
    else:
        return 0, "parameter too large"

func test():
    var result: int 
    var err: error
    result, err = do_something(42)
    if err != null:
        # handle error

[atirut-w]

A lot of Lua programs also do this although with 0 replaced with a nil and the caller checking if a nil is returned. This method works very well for most use cases.

I am more inclined to use assert and error, though.

[zinnschlag]

Then you still have error handling code mixed in with the logic. Not much of an improvement. Guess we have to agree to disagree here. At least for application level code I would consider exceptions to be without alternative.

[miv391]

We have different opinions about errors. I think errors are normal part of program logic and they shouldn't be separated from it. Code must be built so that error cases are sensibly handled and code keeps on executing. What I proposed is not error recovery, it's error handling.

[zinnschlag]

Seems we have different definitions of the word error. If it is part of the program logic, then it is an expected outcome (vs something that went wrong). That is by my definition not really an error; at least not the kind of error we are discussing here. For this kind of "error" GDScript is already adequately equipped IMHO.

[azur-wolve]

I understand the interest on exceptions by means of "writing software". (for developing tools/other software)

But for gamedev it isn't really desirable, its better to use system of error codes, as Godot's main concern is to develop games.
(not sure about the "zero-cost errors" thing, though)

Not sure of how viable is to implement exceptions for GDScript;
it isn't too fast, and maybe as scripting language interpreted at run-time could throw some inconvenient, but not sure.
If it requires much refactoring so its even less probable.

What problem you have with using error codes?
Those can be used for both tell to the programmer the error, and to automate solutions via code by evaluating such error code.

[zinnschlag]

But for gamedev it isn't really desirable,

I strongly disagree with this statement. Games are software. By applying solid software engineering principles we make more robust and less buggy games. By not applying them we end up with buggy messes of a game (as it is still common, unfortunately).

As explained above with error codes you need to interweave errors checks and error handling within your program logic. This reduces maintainability and increases the chance of missing something. Exceptions on the other hand allow you to separate error handling from the logic. This results in simpler code and it is cleaner and overall less error prone. And as an additional advantage you can ensure that you have enough context at the point of handling the error to actually properly handle the error. That is not necessary the case at the point where the error is generated (especially critical in the case of deeply nested functions).

Also, using error codes limits the constructs you can have within your language. Let's take C++ as an example. It is impossible to use error codes in a constructor or an operator. Not an immediate concern for GDScript. But it puts a hard cap on some enhancements that could be made in the future.

[azur-wolve]

About your example with C++, it can be worked around by using classes/objects, extra work ofc.

My main concern regarding the inconvenience of using exceptions for gamedev is that they're slow at run-time.
(also confusing/hard to use for beginners)

But thats why said that not sure regarding zero-cost exceptions, as idk about it.

[Calinou]

PS: A proposal was written on the subject a while ago: #3194

[atirut-w]

It doesn't have the exact same objective, though. See the third paragraph.

[atirut-w]

As a very poor excuse to bump this, I would like to add not having a proper exception handling means static functions are nerfed since they either return error value or result. you cannot i.e. make static functions that returns a string and can error.

[azur-wolve]

After reviewing this article..

The problem of error handling couldn't be solved by combining the use of error codes and unit tests?

[atirut-w]

That doesn't cover runtime errors. For some use cases, i.e. integrating an online API, the codes have to 1. throw errors at runtime and 2. catch them and sometimes inform the user what went wrong. This is a very convoluted thing to implement in GDScript at the moment.