Когда использовать утверждения, которые останавливают выполнение программы в UE4

Question

В Unreal Engine 4 существует три разных "класса" утверждения . Все работают как точки останова, если утверждение не выполнено.

1. Сообщение об ошибках и остановка выполнения.

   • check*(): как и assert() в C, можно отключить с помощью DO_CHECK 0
   • verify*(): аналогично check*(), но выражение все еще выполняется в DO_CHECK 0 (например, для присвоений переменных)
   • недостаток: останавливает выполнение программы (приложение заканчивается, пользователи редактора могут потерять несохраненную работу)
   • когда использовать: поймать фатальные ошибки

2. Сообщение об ошибках и остановка выполнения исключительно в отладочных сборках.

   • checkSlow(), checkfSlow(), verifySlow() (см. (1))
   • разница с (1): они активны только в отладочных сборках (когда DO_GUARD_SLOW 1)

3. Сообщение об ошибках (и не не останавливает выполнение).

   • ensure*(): аналогично check*(), но выполнение программы может быть продолжено после перерыва
   • когда использовать: чтобы получить информацию о неожиданном состоянии

     полезно, когда вы хотите проверить код во время выполнения, но вы все равно обрабатываете ошибку

(3) отлично подходит в качестве быстрой альтернативы отладке (где вам необходимо установить точки останова вручную), так как он разбивается на стек кода / вызовов при сбое, но позволяет приложению продолжить работу после этого.

Однако я не вижу значимого приложения для (1) и (2), так как выполнение программы в любом случае останавливается из-за фатального сбоя (приводящего к сбою редактора UE4). Другими словами: вместо того, чтобы перехватить фатальную ошибку с check[Slow]() / verify[Slow](), я также могу позволить ему завершить b / c необработанной фатальной ошибки и проверить стек вызовов после сбоя, чтобы исправить ошибку; вместо проверки стека вызовов из ручного подтверждения.

Итак, мой вопрос: Когда использовать утверждения, которые останавливают выполнение ((1) и (2))?

Аргументация check() , приведенная здесь , кажется, способствует написанию небезопасного кода.

компилятор может оптимизировать код после проверки () в предположении, что условие гарантировано выполнено.