Некоторые предложения по реализации исключений:

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

• Генерируйте исключения только для действительно исключительных ситуаций. Не используйте исключения по мелочам. Если ошибка может быть обработана локально, там ее и обрабатывайте.

• Избегайте генерировать исключения в конструкторах и деструкторах, если только вы не перехватываете их позднее

• Вносите в описание исключения всю информацию о его причинах

• Избегайте пустых блоков catch.

• Рассмотрите вопрос о централизованном выводе информации об исключениях

• Стандартизуйте использование исключений в вашем проекте.

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

• Определите конкретные случаи, в которых код может использовать синтаксис throw-catch для локальной обработки ошибок.

• Определите конкретные случаи, в которых код может сгенерировать исключение, не перехватываемое локально.

• Решите, будет ли использоваться централизованный генератор сообщений об исключениях.

• Определите, допускаются ли исключения в конструкторах и деструкторах.

• Рассмотрите альтернативы исключениям. Вам всегда следует принимать во внимание все возможные методы обработки ошибок:

• локальную обработку ошибок

• возврат кода ошибки

• запись отладочной информации в файл

• прекращение работы системы и др.

А напоследок подумайте, действительно ли вашей программе необходимо обрабатывать исключения. Как заметил Бьерн Страуструп, иногда лучшей реакцией на серьезную ошибку периода выполнения будет освобождение всех ресурсов и прекращение работы. Пусть пользователь перезапустит программу с надлежащими входными данными (Stroustrup, 1997).

Архитектура программного обеспечения

Архитектура программного обеспечения (англ. software architecture) программы или вычислительной системы - это структура или структуры системы, которая(ые) включает(ют) программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. Этот термин также относится к документированию архитектуры программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между заинтересованными лицами (англ. stakeholders), позволяет зафиксировать принятые на ранних этапах проектирования решения о высокоуровневом дизайне системы и позволяет использовать компоненты этого дизайна и шаблоны повторно в других проектах.

Область компьютерных наук с момента своего образования столкнулась с проблемами, связанными со сложностью программных систем. Ранее проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин "архитектура программного обеспечения" является относительно новым для индустрии разработки ПО, фундаментальные принципы этой области неупорядоченно применялись пионерами разработки ПО начиная с середины 1980-х. Первые попытки осознать и объяснить программную архитектуру системы были полны неточностей и страдали от недостатка организованности, часто это была просто диаграмма из блоков, соединенных линиями. В 1990-е годы наблюдается попытка определить и систематизировать основные аспекты данной дисциплины. Первоначальный набор шаблонов проектирования, стилей дизайна, передового опыта (best-practices), языков описания и формальная логика были разработаны в течение этого времени.

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

Являясь в настоящий момент своего развития дисциплиной без четких правил о "правильном" пути создания системы, проектирование архитектуры ПО все еще является смесью науки и искусства. Аспект "искусства" заключается в том, что любая коммерческая система подразумевает наличие применения или миссии. То, какие ключевые цели имеет система, описывается с помощью сценариев как нефункциональные требования к системе, также известные как атрибуты качества, определяющих, как будет вести себя система. Атрибуты качества системы включают в себя отказоустойчивость, сохранение обратной совместимости, расширяемость, надежность, пригодность к сервисному обслуживанию (maintainablity), доступность, безопасность, удобство использования, а также другие качества. С точки зрения пользователя программной архитектуры, программная архитектура дает направление для движения и решения задач, связанных со специальностью каждого такого пользователя, например, заинтересованного лица, разработчика ПО, группы поддержки ПО, специалиста по сопровождению ПО, специалиста по развертыванию ПО, тестера, а также конечных пользователей. В этом смысле архитектура программного обеспечения на самом деле объединяет различные точки зрения на систему. Тот факт, что эти несколько различных точек зрения могут быть объединены в архитектуре программного обеспечения является аргументом в защиту необходимости и целесообразности создания архитектуры ПО еще до этапа разработки ПО.