AlexXYZ
@AlexXYZ
O Keep Clear O

Номера ошибок. Требуется однократно указать номер ошибки в коде. Есть хорошая практика?

Привет.

Есть бизнес-логика работы с большим списком параметров. Есть много условий по проверке сочетаемости параметров. Фактически требуется "просто" ))) пронумеровать условия. Если условие сочетаемости неверно, то нужно добавить в "стек ошибок" этот самый уникальный код ошибки. Обязательное условие - код ошибки должен быть постоянен (однажды присвоенный код не должен меняться, т.е. инкремент переменной кода ошибки запрещён!). И вот это создаёт проблемы в развитии программы. Если предположить, что изначально список условий и кодов был последовательный, то вносить изменения в проверку условий можно и в середине кода, соответственно последовательность перестаёт быть "ровной". Если для ошибок использовать только числа, то легко запутаться, какие числа я уже использовал.

Вопрос - как быть?

P.S.
Пока выкручиваюсь тем, что перед присвоением номера просто проверяю поиском, что данное число ещё не использовалось, например, ищу "mcode = 42;" если не найдено в исходнике, то использую, а вот если найдено, то приходится перебором искать максимальное.

РЕШЕНИЕ:


5b2363d25e8cc446989262.gif


Дополнение
Пошёл немного дальше и теперь не использую переменных при регистрации ошибок, а сразу пишу номер ошибки:

5b28cd1879bf5149923206.png
  • Вопрос задан
  • 245 просмотров
Решения вопроса 1
@Beltoev
Живу в своё удовольствие
По описанию задачи и вашим комментариям к ответам, думаю, понял, что вам нужно, поэтому следите за руками (решение не стандартное, но полностью решающее вашу проблему):

1. Создайте класс-контейнер, в котором будут сохраняться все ошибки. Назовём его, например, ErrorsContainer:
public class ErrorsContainer
{
    // Пример ошибки
    public object Error23;
}


2. Теперь добавьте класс, который будет возвращать код ошибки по полю класса-контейнера. Назовём его 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. Сложная часть позади. Теперь можно использовать в коде следующую конструкцию:
int error23 = Error.Get(nameof(ErrorsContainer.Error23));


Теперь у вас в коде будет контроль всех существующих ошибок (они будут расположены в ErrorsContainer) и новые ошибки будут добавляться буквально одной комбинацией (Alt + Enter, Enter в Resharper-е). Главное, не забывать использовать nameof.

Пример добавления новой ошибки (напоминаю, Alt + Enter в Resharper на раскладке IntelliJ IDEA):
5b22949c27f63103527770.png
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
@Sumor
Используйте для своих ошибок свой класс исключений. Так вы отделите свои ошибки от чужих.
В качестве номера ошибок используйте enum с явным указанием числового значения - с одной стороны в своём коде вы используете понятные буквенные обозначения, с другой - у вас есть их числовое значение.
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;
  }
}
Ответ написан
Jeer
@Jeer
уверенный пользователь
Возвращать кастомные номера ошибок в принципе плохая практика.
Если у вас большой список параметров, то оборачивайте их в класс данных, dto.
Далее, вам нужна валидация. Из коробки доступна схема работы с ModelState - это когда в декларативном стиле описываются правила и на выходе есть метод isValid - валидна ли модель и весь список ошибок, если не валидна. Для зависимых полей приходится писать кастомные классы-валидаторы, это не всегда удобно, но можно писать правила любой сложности.
Второй вариант, это вы подключаете fluent validation, и во внешних классах описываете все правила. Как по мне, у них сложноватый синтаксис, поначалу немного пугающий, но в целом всё отлично работает.
Ответ написан
@nexus478
Сделайте отдельный класс, который будет хранить список условий или отдельное свойство типа
Dictionary<int, bool>  (номер правила и нарушено/не нарушено)

в классе, которой осуществляет валидацию. Что-то нарушилось - поставили по нужному правилу false. В конце потом можете вытащить все ключи со значением false, вот вам и будет список ошибок.

А вообще было бы неплохо узнать, как выглядит класс валидации и как выглядит класс-клиент, который ожидает коды ошибок.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы