These are not exceptions so we don’t need multiple variants of
generic error in case someone wants to catch it somewhere
up the call stack.
It’s okay to use UNKNOWN for generic errors where we don’t know
exactly what happened.
This concludes the implementation of the in-memory NBT representation.
This is still all untested code so it might just blow up in your face.
The next step will be writing tests (and probably a lot of cursing and
debugging)...
One for serializing full tags and one for serializing tags without
their header.
The former is what used to be `toRawData` - though a bunch of
duplicated code has been removed by just moving it to the Generic
type class instead of having an implementation on the sub-classes.
The latter is useful for serializing lists.
The previous warning that all of this is untested still applies.
This is still all unvalidated work.
For all I know it might cause your computer to burst into flames,
grow an arm and a leg and an eye, and attack you with a sword.
But probably, it will just not work and I will realize that sleepy
past me was a fucking idiot (as always).
The former is finally some progress on getting NBT going,
though at this point it is all unvalidated work.
For all I know it might cause your computer to burst into flames,
grow an arm and a leg and an eye, and attack you with a sword.
But probably, it won’t do that and instead start working after I
have debugged it so much that I wish I could attack my PC with a sword.
The latter is the implementation of a change I prepared in a previous commit
when i added ErrorOrVoid.
I stumbled over this when writing the unit test. Previously, it would return
an error code but explicitly mark it as not being an error. This was intended
behavior but I decided to change it because I didn’t anticipate it when writing
the test.
Technically `ErrorOr<T>` can be used to pass any message alongside `T`,
but practically, it is reasonable to assume that the error code is
`ErrorCodes::SUCCESS` when `isError` is false. Therefore, this feature
should be really only used in the weirdest edge cases - if at all.
Even then, it is most likely still preferable to flag it as an error and
just hand the resulting `T` back using the long constructor
`ErrorOr<T>(bool, uint8_t, T)`.
I tried dealing with lists in the same way as with other more basic tags
but came to the conclusion that this is most likely not feasible in the same
way that it is not feasible for compounds. It would require a mini-parser
that can deal with all sorts of tags (including nested lists and compounds).
Instead, an approach more similar to the recursion for compound tags will
be used (using its own function to deal with the missing tag headers ofc).
BodgeMaster