Almost out of free error IDs

[Daniel-Cortez]

Issue description:

Currently we have only 5 free error IDs left (95-99), which might be not enough when implementing new features such as #234, #608 and #609, so we should probably prepare for this in advance.

We could do either of the following:

• Relocate fatal errors to a new range. We have 12 fatal errors in total (100-111), so I think a range of 180-199 should be more than enough. This way we'll have a single unbroken range for regular errors (1-179), but the IDs of fatal errors would change, so we'll have to update a couple of tests.
• Allocate a new range for new error IDs. This will allow us to keep the same IDs for fatal errors, but we'll have 2 ranges for regular errors, which would increase the code complexity.

So, which option would be more preferable?

Personally I'm in favor of the 1'st one, as I think having a single range for regular errors is more important than keeping the old IDs for fatal errors.

Minimal complete verifiable example (MCVE):

--

Workspace Information:

• Compiler version: 3.10.10
• Command line arguments provided (or sampctl version):
• Operating System:

[Cheaterman]

(hopefully my 2¢ are welcome...) AIUI there is no backwards compat to be worried about here - fatal errors probably can't be ignored, so there's no bit of code (#pragma or compiler cmdline) that would depend on the old IDs.

On the other hand, there's obvious benefits to have a single unbroken range for regular errors.

I don't know if it makes sense at all, but what about having 1-199 be normal errors and 200+ be fatal? This way, it would be as easy as HTTP to determine what category of error you're facing.

[Y-Less]

That's a very good thought. In fact, even normal errors can't be ignored (since they're code that can't be compiled).

[Daniel-Cortez]

what about having 1-199 be normal errors and 200+ be fatal?

The range of 200+ is already occupied by warning IDs - changing them would break a lot of code that uses #pragma warning enable/disable. Relocating fatal errors to 300+ is probably OK, but considering how much potential there might be for implementing new compiler diagnostics (warnings), I think a range of 400+ would be safer.

[Cheaterman]

Further making them look like HTTP error codes, hahaha. I kinda like it? ☺

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.