Утверждение, Исключение, ошибка времени выполнения или Неопределенное поведение?

Question

Я работаю на конечную государственную библиотеке машины, с этими общественными методами:

template <typename STATE_T> 
void add_state();    // allocate STATE_T on heap - STATE_T must derive from state 

template <typename FROM_STATE_T, typename TO_STATE_T> 
void link_state(std::function<bool()> cond, unsigned int priority); 

// search for base state pointer that can be dynamically caste d to STATE_T* type, set this state as the beginning state 
template <typename STATE_T> 
void begin_state(); 

void execute(); 

//STATE_T must be a user defined state class that inherits from the base state class. 

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

Вот ограничения Я хочу, чтобы обеспечить соблюдение:

1. Невозможно добавить повторяющиеся состояния
2. Не удается связать состояния, которые не существуют (например, как государственного типа (т.е. добавление двух же производного типа.) не в ФШМ списке состояний)
3. государства должны иметь точку входа/достижимым
4. начала и конечное состояние должно существовать
5. выполнить не может быть запущен несколько раз одновременно

Утверждение отменяет программу и четко придерживается этих ограничений, но является ли это правильным выбором?

Возможно, что 1,2,3 будут нарушены, а fsm все еще будет в правильном состоянии (просто ничего не делать), но мне не нравится идея неявно обращаться с ними, поскольку она вводит ложное чувство безопасности посредством скрывая ошибки программиста.

Если я выбрал исключения для 1,2,3, и программист поймал их, то fsm все равно может находиться в допустимом состоянии, что позволяет плохо сформировать fsm для запуска.

5 Это то, что не должно быть сделано. должен ли я справиться с этим или оставить его как UB?

Каким будет наиболее подходящий механизм для использования этих ограничений?

Answer 1

Это довольно типичная проблема обработки ошибок. Ответ обычно зависит от затрат. Какова стоимость проблемы, которая останется незамеченной? Какова стоимость прерывания программы за счет исключения?

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

Существует гибридный подход: в сборке DEBUG обрабатывать сообщение с сообщением «Assertion failed» (обычно это делается с помощью макроса ASSERT()), но в сборке Release обрабатывайте ошибку молча. Это, однако, позволяет проблеме оставаться незамеченной на компьютерах клиента, часто вызывая другие ошибки, которые трудно найти.

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