Как бороться с недействительными бизнес-объектами в коде?

Question

Допустим, у вас есть бизнес-объект, текущее состояние которого означает, что в вашем коде есть какая-то ошибка. Или, в основном, любой сценарий, в котором вы работаете со своими собственными данными, но он никогда не нарушает некоторые правила. Мне нравится обычно проверять наличие таких условий и предположений, потому что это позволяет мне обнаруживать ошибки на ранних этапах ближе к их источнику. Однако, какова лучшая практика, если такая логическая проверка не проходит?

Я знаю, что операторы Debug.Assert очень удобны для этого, однако я их не очень люблю, потому что они появляются только в режиме отладки, а не в фазе тестирования или выпуска, которая, очевидно, все еще может содержать много таких ошибок. Я бы предпочел быть информированным о том, что эта проверка не выполняется, а не пытается отладить проблему, которая возникает много позже в коде. Решение для меня выглядит как бросание исключения какого-то рода. Это хорошая идея?

Answer 1

Ты абсолютно прав, брось исключение.

Вы можете расширить класс Exception и использовать свою расширенную версию для этих случаев, это позволит вам обрабатывать их далее по цепочке для регистрации и остановки приложения при необходимости.

try
{
}
catch(MyException ex)
{
   ex.LogError();
   if(ex.IsCritical)
     throw ex;

}

Answer 2

Я обычно проверяю такие проблемы в самом бизнес-объекте и выкидываю исключения, в которых игнорирование приведет к объекту с недопустимым состоянием. Такие исключения включают (но не ограничиваются ими):

1. IllegalArgumentException для передаваемых аргументов, которые неприемлемы (например, ноль, где не разрешено)
2. IllegalStateException для случая, когда объект может быть переведен в неправильное состояние (отличается от сценария, в котором аргумент недопустим)

Таким образом, сам бизнес-объект никогда не является недействительным.

Я немедленно проверяю эти ситуации. Сценарий, которого я отчаянно пытаюсь избежать, - это изменение объекта таким образом, чтобы он находился в недопустимом состоянии, и обнаружение этого только позднее (возможно, спустя годы - представьте, что сериализовать такой объект и десериализовать его через год). Это сделало бы открытие источника таких проблем почти невозможным.

Я, конечно, хочу, чтобы эти проверки проводились как на этапе производства, так и на стадии разработки / тестирования. Обычно затраты на выполнение таких проверок незначительны по сравнению со временем, затрачиваемым на нормальную работу, и особенно по сравнению с количеством времени, которое потребуется вам, чтобы отказаться от такого сценария.

Answer 3

Да, это правильный способ сделать это, по моему мнению. Исключение будет всплывать и не останется незамеченным, что позволит вам вернуться к источнику проблемы.