Rework server.ini parsing to not depend on the real console #1659
Conversation
| ST::string Parse(const plFileName& fileName); | ||
| void Apply(); | ||
|
|
||
| static ST::string Load(const plFileName& fileName); |
There was a problem hiding this comment.
I have a preference for returning a boolean status value and having the error string fetch being a separate call.
There was a problem hiding this comment.
Would a boolean return and an out parameter for the error message be okay too?
static bool Load(const plFileName& fileName, ST::string& errorMsg);pfServerIni::Load is a static method and I would rather not introduce a new global "last error" variable just for this one call...
There was a problem hiding this comment.
That's a good point. I was thinking that the error should be a class member that can be fetched with a getter, and the client code would do something like the body of Load(). I'm not a big fan of out parameters in C++ - I know there are some in the engine already, but they are a code smell IMO. I would consider throwing an exception acceptable as well. I generally don't care much for those either, but this isn't performance sensitive code, and it feels like a more natural way of receiving an error as opposed to an error message return.
There was a problem hiding this comment.
Hmm. Genuine question: why exactly do you prefer a separate GetErrorMsg function/method? To me, it seems like it just has lots of disadvantages (forced shared state for no good reason, every class needs its own error variable/getter, it composes badly, and it's easy for callers to miss that there is an error message at all). All of the alternatives (error message in return value, as an out parameter, or an exception) have less of these issues and just seem better to me, even if they're a little awkward in other ways. I think the ideal solution would be std::expected, but that only exists since C++23...
Exceptions would probably work well enough though. I guess I should define a custom exception specifically for this API, similar to e. g. plPXCookingException?
There was a problem hiding this comment.
To me, returning an error message and testing its emptiness isn't a great way to communicate success. There are plenty of libraries out there that use error codes and have strings for "Success," and it's not uncommon to see amusing situations where users get "Error: Success". I know this isn't an error code, but who knows who will come behind us and not realize an empty string is success. I would prefer an explicit, easily understandable success condition. Out parameters do that, but are C style. This is C++, where we have more idiomatic ways of doing things. Those can be members with a getter, exceptions, tuples (and, with C++17, structured bindings to unpack the return value), or, as you mention, std::expected in C++23.
Edit: And, yeah, I would probably make a custom exception similar to plPXCookingException.
dgelessus
force-pushed
the
server_ini_parsing
branch
2 times, most recently
from
ad7788f to
c54e52e
Compare
The commands under the Server group are only meant for server.ini files and aren't usable anywhere else. Similarly, server.ini files aren't supposed to call any other console commands. This is now enforced by not handling the server settings as real commands, but with a new dedicated server.ini parser that handles only server settings and nothing else. This new parser intentionally doesn't support some obscure features of the full console, such as spaces as command group/name separators (e. g. "Server Status" instead of "Server.Status") and console variables. This is strictly speaking a breaking change, but unlikely to cause issues - these features were never documented and are unused in practice.
This is now in pnNcEncrypt.cpp.
dgelessus
force-pushed
the
server_ini_parsing
branch
2 times, most recently
from
bd58629 to
e411269
Compare
Use the methods FromData_BE and FromData_LE instead, which make the endianness explicit (or rather, more explicit than an unnamed bool parameter with a default value).
dgelessus
force-pushed
the
server_ini_parsing
branch
from
e411269 to
8d47cde
Compare
Reworks how server.ini files are parsed, based on my console parsing refactoring in #1459. Advantages of this reworked code include:
Also includes some bonus refactoring of how the Diffie-Hellman keys are stored and passed around.
Example of the new error messages: