Error numbers. It is required to specify the number of the error in the code once. Is there a good practice?

Question

C++ / C#

Hello.
There is a business logic for working with a large list of parameters. There are many conditions for checking the compatibility of parameters. In fact, it is required to "simply" ))) enumerate the conditions. If the compatibility condition is false, then this very unique error code must be added to the "error stack". A prerequisite is that the error code must be constant (once the assigned code must not change, i.e. incrementing the error code variable is prohibited!). And this creates problems in the development of the program. If we assume that initially the list of conditions and codes was sequential, then it is possible to make changes to the condition check in the middle of the code, respectively, the sequence ceases to be "smooth". If only numbers are used for errors, it is easy to get confused which numbers I have already used.
Question - how to be?
PS
For now, I get out by the fact that before assigning a number, I simply check with a search that this number has not yet been used, for example, I search for "mcode = 42;" if it is not found in the source, then I use it, but if it is found, then I have to search for the maximum by brute force.
SOLUTION: Addition I went a little further and now I do not use variables when registering errors, but immediately write the error number:

Answer 1

According to the description of the problem and your comments on the answers, I think I understood what you need, so watch your hands (the solution is not standard, but it completely solves your problem):
1. Create a container class that will store all errors. Let's call it, for example, ErrorsContainer:

public class ErrorsContainer
{
    // Пример ошибки
    public object Error23;
}

2. Now add a class that will return an error code for the field of the container class. Let's call it Error:

public static class Error
{
    private static readonly Regex Regex = new Regex(@"\d+", RegexOptions.Compiled);

    public static int Get(string fieldName)
    {
        return int.Parse(Regex.Match(fieldName).Value);
    }
}

3. The hard part is behind you. Now you can use the following construct in your code:
Now you will have control over all existing errors in your code (they will be located in the ErrorsContainer) and new errors will be added with literally one combination (Alt + Enter, Enter in Resharper). The main thing is not to forget to use nameof.
An example of adding a new error (remember, Alt + Enter in Resharper on the IntelliJ IDEA layout):

Answer 2

Use your exception class for your errors. This way you can separate your mistakes from others.
As an error number, use enum with an explicit numeric value - on the one hand, you use understandable letter designations in your code, on the other hand, you have their numeric value.

public MyException : Exception
{
  public enum MyErrorCodeEnum { Error1 = 1, Error2 = 2, Error22 = 22};
  
  private MyErrorCodeEnum _myErrorCode;
  public MyErrorCodeEnum MyErrorCode
  {
    get {return _myErrorCode;}
  }

  public MyException(MyErrorCodeEnum errorCode)
  {
    _myErrorCode = errorCode;
  }
}

Answer 3

Returning custom error numbers is generally bad practice.
If you have a large list of parameters, then wrap them in a data class, dto.
Next, you need validation. Out of the box, a scheme for working with ModelState is available - this is when the rules are described in a declarative style and there is an isValid method at the output - whether the model and the entire list of errors are valid, if not. For dependent fields, you have to write custom validator classes, this is not always convenient, but you can write rules of any complexity.
The second option is that you connect fluent validation, and describe all the rules in external classes. In my opinion, they have a complicated syntax, a little intimidating at first, but in general everything works fine.

Answer 4

Make a separate class that will store a list of conditions or a separate type property

Dictionary<int, bool>  (номер правила и нарушено/не нарушено)

in the class that is validating. Something was broken - set false according to the desired rule. At the end, you can then pull out all the keys with a value of false, so you will have a list of errors.
In general, it would be nice to know what the validation class looks like and what the client class looks like, which expects error codes.