[OT] Godot Engine: Disable C++ exception handling

Aug 15

ryuukk_

Aug 15

ryuukk_

Aug 15

Aug 18

Aug 18

Aug 18

August 18

Re: [OT] Godot Engine: Disable C++ exception handling

Posted by Hipreme
in reply to ryuukk_

Permalink

Hipreme

Posted in reply to ryuukk_

Permalink

On Tuesday, 15 August 2023 at 02:21:43 UTC, ryuukk_ wrote:

I always been advocating against EH

This is another missed opportunity at capturing that audience

I think the builtin tuple DIP must be resumed right away once D no longer is frozen

https://github.com/godotengine/godot/pull/80612

I have been saying about how exception handling wasn't a good fit for game development, as I said before, games should fail as soon as possible, since they are super easy to enter in an invalid state, they're the completely the opposite from servers. Hipreme Engine is being developed completely without exceptions. I had to develop my own JSON solution since the std.json one uses exception, and also talked with p0nce about his libraries to not use exceptions.

The only place I use exceptions/error handling are in the hot reloading functionality since the user code can easily do errors such as

int[] a;
a[0] = 50;

This will cause an AssertError, which my engine will handle manually to unload the shared library.

Also, my own JSON implementation consistently got 50% of the time used by std.json, probably for not throwing any kind of error, it is almost a drop-in replacement for it, except you manually check after parsing.

On 8/15/23 04:25, ryuukk_ wrote: > 6 years ago: https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md > > What happened for things to stop moving? D is in best position to be leading at doing better than C/C++ I got very busy with work (both day job and other volunteering engagements) and personal issues. Also quite a few people are pushing for the scope of that DIP to be expanded beyond what can reasonably be expected to be put into the language and I am not really motivated to fight about it. As a result the implementation of the feature is not finished. Also, some parts of the design do still need to be improved.

On Friday, 18 August 2023 at 10:06:44 UTC, Hipreme wrote:

Also kinda in the process of removing exceptions, in order to converge upon the custom WebAssembly druntimes that float around. Our exceptions were manually allocated anyway with a bearing on the catcher.
A pattern that can help is the fail() bit a bit like std::file or FILE*. It's the same morass of error codes and boolean a bit everywhere, but we can hide it from the library user.
For parsers, having popBack() throw is expensive so it can be valuable too to lessen exception usage.

Forums