Защитное программирование

Чтобы не забыть и чтобы было куда посылать...

Часть мыслей честно утащена у Эккеля и других авторов, здесь сведено в одну таблицу и отражена суть что и где применять. Вопрос “когда применять” не рассматривается, ибо не корректен – применять надо всегда.

Есть 3 вида конструкций для защитного программирования: исключения, assert’ы и проверки. Применять при:

	Исключения	assert’ы	логические проверки
взаимодействия с внешними системами и сторонними модулями	да	нет	да
создание новых объектов	да	нет	нет
своя логика	нет	да	да
проверять юнит тестами поведение?	нет	да	да
оставлять в релиз версии	да	?	да

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

Создание новых объектов – тут кроме исключений больше ничего не поможет защититься от ошибок.

Своя логика – проверять что ты ничего вредного или чудного не передаёшь внутрь.

С юнит тестами связан следующий момент: 
все три конструкции должны проверять только важное на данном этапе, а не всё подряд – иначе это может привести к сложностям при написании юнит тестов. Подробней смотреть link.

Оставлять в релиз версии – а вот тут есть разные мнения. Начиная от сравнения “ходить по суше в спасжилете, а перед выходом в море снимать его” и заканчивая “не нужно нам неконтролируемое падение системы”. Пмм, на этапе тестирования лучше иметь ассерты – более заметны, а соответственно лучше стимулируют исправление; а вот на этапе установки у заказчика лучше иметь логические проверки с логированием.