drug007, ответ кроется в вопросе: если недостаток релиза в отсутствии диагностики, её надо добавить (логи).

Лучше мне пока на ум ничего и не пришло. Но тут меня смущает то, что когда у тебя приложение упало в ассерте сразу понятно, где искать. А при логировании это уже не так очевидно. Т.е. роль логов резко вырастает, придется их семантику продумывать тщательно - потому что обычно логи ведутся на всякий случай по остаточному принципу... В общем логи либо оставлять в релизе диагностические средства, которые не критичны для приложения (не влияют на скорость или влияют некритично и т.д.). Получается два варианта?

запишите в лог то же самое


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

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

Мне кажется, что проблема не в наличии или отсутствия логов и/или ответа на вопрос - падать или не падать. Проблема более глобальная - у вас есть проверка/assert (положим что она осталась и в релизе), и есть требование, что бы программа обладала максимальной живучестью, т.е. не падала.
Что делать если assert стработал - правильно функуционировать программа уже не может, но и падать нельзя. И что делать?
Проблемы с отказами и сбоями в отвественных приложениях обычно решают дублированием, но в данном случае это не сработает - если ошибка была в программе, то и дубль так же упадет. Тут может помочь только дублирование на уровне функционала, т.е. параллельно работающая фетка с той же функциональностью, но возможно с какими то недостатками (типа недостаточной производительности или большим требованием к ресурсам), что бы при выходе из строя основной ветки ее функции мог подхватить дубль (и не упасть при этом). Конечно дубль должен быть максимально простым и дубовым. Увы не всегда такой можно сделать   

Класс задач простой - улучшить поддержку развернутого приложения, в частности упростить работу с ошибками, обнаруженными в релизе. Банально, у нас нет возможности тестировать на всем оборудовании. Определенная работа проведена по достижению воспроизводимости ошибки, чтобы логи, записанные у пользователя, позволяли однозначно воспроизвести ситуацию у нас. Теперь надо определиться с политикой, как реагировать на ошибки логики - когда мы точно знаем, что логика нарушена, но исправить ее не может. Раньше я просто ронял приложение, но сейчас есть противоречащее требование. Вот и думаю, как и волка накормить, и овец спасти.

Да, вы верно описали ситуацию. Получается есть еще третий вариант - дублирующий код. Кстати, в некоторых ситуациях такой подход очень даже обоснован, спасибо за подсказку.

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

Это сообщение отредактировал(а) baldina - 19.1.2015, 17:32

Нашел несколько статьей на эту тему:

http://www.billpetit.com/Papers/Petit019.pdf


Присоединённый файл ( Кол-во скачиваний: 3 )
 00056848.pdf.zip 555,79 Kb

Еще одна

Присоединённый файл ( Кол-во скачиваний: 4 )
 00056849.pdf.zip 665,24 Kb

И последняя


Присоединённый файл ( Кол-во скачиваний: 7 )
 00056850.pdf.zip 898,34 Kb