Вместо эпиграфа: «Менеджеры бывает разные — черные белые красные...»

И еще раз вместо эпиграфа: «А я здесь живу… И хочу, чтобы в этой стране все было как-то нормально» — Духless

Почти полтора года прошло с момента публикации первой части марлезонского балета. Тогда акцент был сделан на процессы, методы разработки ПО в реалиях сегодняшнего дня, на том, как два мира — по-детски наивный и простодушный инженерный и местами весьма дурно пахнущий «деловой» пытаются усидеть за одним столом. Изменилось ли что-либо в лучшую сторону — сомнительно, но думаю так или иначе стоит продолжить и перенести акцент с рассмотрения процессов на рассмотрение людей, вернее тех людей, кто эти самые процессы должны определять, «ставить» на проектах, а именно на менеджеров продуктов или менеджеров проектов или руководителей проектов, «имя им легион».

Где-то я слышал, что в психотерапии существует следующая методика работы с пациентом – пациенту предлагают сесть и написать в свободной, «потоковой» форме все что накипело, волнует, будоражит сознание и, отражаясь на подсознании, не дает спать по ночам. Применительно к этому есть хорошее, нежно ласкающее слух слово – фрирайтинг.

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

Написано уже немало про обработку исключений в C#, написано хорошо и местами подробно, но я попытаюсь внести свою скромную лепту в этот вопрос. Данная статья является просто некой попыткой лучше осмыслить и систематизировать в рамках одной, пусть даже очень условной концепции возможные подходы к проблеме. Хорошая практика обработки исключений, на мой взгляд, освещена довольно скудно и не создает целостной завершенной картины, когда, как и где работать с исключительными ситуациями в коде.