Приветствую. Длинно и сумбурно, но короче не знаю как

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

В результате с одной стороны в коде есть проверки ассертами на невалидные ситуации, но с другой стороны есть проверка возвращаемых значений, проверка входных параметров, там где нужно try/catch и т.п. — т.е. в любом случае пытаемся спасти ситуацию.

Т.е. если утрировать то например есть функция возвращающая некую структуру описывающая игровой объект по его id.

Если подсунуть невалидный id, в дебаг версии она упадет с ассертом (а нефиг подсовывать объекты которые в контент не добавлены), в релизе вернет нулевой указать, на который хорошо бы потом проверить. Ну или упадет с ассертом в случае если вообще коллекции с объектами нету (не отгрузили в контент), а в релизе опять же вернет нулевой указатель.

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

Вот хотим написать тест на данную функцию в которую мы передаем заведомо невернный айдишник и что она обработает нормально.

Как мы пишем

#ifdef DEBUG
ASSERT_THROW(someFunc(notValidId));
ASSERT_NOT_THROW(someFunc(validId));
#else
ASSERT_EQ(someFunc(notValidId), NULL);
ASSERT_NE(someFunc(validId), NULL);
#endif

Или пишем два набора тестов? Или забиваем на дебаг вообще?

Здравствуйте, Young, Вы писали:

Y>Или пишем два набора тестов? Или забиваем на дебаг вообще?

Вообще, держать 2 набора тестов — это накладно, так как удваивается нагрузка на разработку и поддержку. От дебага отказываться не надо, если информация, полученная в этой конфигурации представляет интерес. Возможно, лучше как-то переопределить сами assert-ы, чтобы в дебаг конфигурации происходил крэш, а в релизе обрабатывались тяжелые ситуации. Тогда набор тестов будет идентичен. А такое разветвление на Debug/Release будет локализировано несколькими файлами.

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

Здравствуйте, Young, Вы писали:

Y>Если подсунуть невалидный id, в дебаг версии она упадет с ассертом (а нефиг подсовывать объекты которые в контент не добавлены), в релизе вернет нулевой указать, на который хорошо бы потом проверить.
используйте исключения вместо проверки нулевых указателей. и вместо ассёртов тоже.

кстати, ассёрт должен завершать приложение, а не бросать исключение.

Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, Young, Вы писали:

Y>>Если подсунуть невалидный id, в дебаг версии она упадет с ассертом (а нефиг подсовывать объекты которые в контент не добавлены), в релизе вернет нулевой указать, на который хорошо бы потом проверить.
A>используйте исключения вместо проверки нулевых указателей. и вместо ассёртов тоже.

Исключения в нашем случа это примерно -5% производительности, мы измеряли. Но как бы ок.
Но, с ассертами не понятно — ну вот напишем мы trow -1, не будем его отлавливат и на том же iOS мы не получим нормального крашрепорта со стеком вызовов, в отличии если мы SIGABRT пошлем в этот момент.


A>кстати, ассёрт должен завершать приложение, а не бросать исключение.

Может не так сформулировал. Ассерт посылает SIGABRT и на ряде платформ это единственный способ получить информацию с девайса какую либо нормальную.

Или вы не о том?

Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, Young, Вы писали:

Y>>Если подсунуть невалидный id, в дебаг версии она упадет с ассертом (а нефиг подсовывать объекты которые в контент не добавлены), в релизе вернет нулевой указать, на который хорошо бы потом проверить.
A>используйте исключения вместо проверки нулевых указателей. и вместо ассёртов тоже.

A>кстати, ассёрт должен завершать приложение, а не бросать исключение.

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

Здравствуйте, Young, Вы писали:
...
Y>В результате с одной стороны в коде есть проверки ассертами на невалидные ситуации, но с другой стороны есть проверка возвращаемых значений, проверка входных параметров, там где нужно try/catch и т.п. — т.е. в любом случае пытаемся спасти ситуацию.

Т.е. вы вот так пишете:?

void f(some_type v)
{
   assert(v != some_value);
   if(v == some_value)
   {
     //...
   }
}

Если да — скажи как игра называется, что бы я знал что не надо покупать...