fennec-org/fennec
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

- Wrote and Debugged Unit Tests for fennec::file

Browse Source
This commit is contained in:
Medusa Slockbower
2025-07-14 21:15:39 -04:00
parent 6ae682aff6
commit 89f59c75f3
14 changed files with 669 additions and 369 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
README.md
View File

@@ -65,24 +65,24 @@ fennec Standards:
called `detail`. Helper functions should be documented with C-Style comments, however it is not necessary to provide
Doxygen documentation.
- **DO NOT USE C++ EXCEPTIONS** they will not be supported because they are shit. No, I won't elaborate.<sup>[[1]](#f1)</sup>
- **DO NOT USE C++ EXCEPTIONS** they will not be supported because they are shit.<sup>[[1]](#f1)</sup>
* Most behaviours should be type independent. Specifically interactions with the core systems of the engine.
<br><br>
<a id="f1"></a>
<sup>[1]</sup> Okay, I will elaborate. If we were to use the exception paradigm for all erroneous behaviour, we couldn't
guarantee that the state will not be corrupted when an exception is thrown. The behaviour afterward is
undefined because of this, and we also don't really know when, how, or where that exception will be handled.
The assertion paradigm is better at handling this because you are defining erroneous behaviour in the code and how
it is handled. In a debug build we can immediately halt the program, we don't care about the state afterward, only
beforehand. Now for a release build, this is first and foremost a game engine, so we want to crash as gracefully as
possible, prevent data loss, and get some debug information for it. fennec defines its own `assert` macro to
be used, defining a hook in the private version of the function. This hook is used to clean up any state information
within the engine and may be used to send immediate events to listeners so that outside functionality may decide
how to handle the impending crash. In Debug Mode there is nothing that can be done to stop the crash, as soon
as the branch finishes, `abort()` will be called.
<sup>[1]</sup> If we were to use the exception paradigm for all erroneous behaviour, we couldn't
guarantee that the state will not be corrupted when an exception is thrown. The behaviour afterward is
undefined because of this, and we also don't really know when, how, or where that exception will be handled.
The assertion paradigm is better at handling this because you are defining erroneous behaviour in the code and how
it is handled. In a debug build we can immediately halt the program, we don't care about the state afterward, only
beforehand. Now for a release build, this is first and foremost a game engine, so we want to crash as gracefully as
possible, prevent data loss, and get some debug information for it. fennec defines its own `assert` macro to
be used, defining a hook in the private version of the function. This hook is used to clean up any state information
within the engine and may be used to send immediate events to listeners so that outside functionality may decide
how to handle the impending crash. In Debug Mode there is nothing that can be done to stop the crash, as soon
as the branch finishes, `abort()` will be called.
<br>