Стоит ли ловить исключения по указателю в MFC, или тебе лучше использовать другой подход?

Особенности, специфичные для фреймворков

Если ты используешь MFC или другие устоявшиеся фреймворки, следуй их соглашениям по обработке исключений. Когда берёшь фреймворк, принимай его идиомы и паттерны проектирования, а не пытайся навязать свои подходы. Но если ты строишь свой собственный фреймворк или независимый код, то избегай catch по указателю.

Почему MFC использует catch по указателю

Библиотеки вроде MFC появились раньше стандартной обработки исключений в C++. Они используют обратно совместимую обработку исключений на основе указателей, которая требует или поощряет catch по указателю. В своё время это было практичным решением, но в современном C++ это создаёт серьёзные проблемы.

Проблемы с catch по указателю

Catch по указателю создаёт три главные проблемы:

• Неясная ответственность: часто непонятно, должен ли блок catch вызвать delete для указателя. Представь, что ты бросаешь и объекты в куче (throw new MyException), и объекты из стека (throw &local). Блок catch не может безопасно определить, какой подход был использован.

• Нагрузка на выделение памяти: если ты постоянно используешь new для всех бросаемых исключений, ты создаёшь давление на кучу в ситуациях с нехваткой памяти — именно тогда, когда обработка исключений критична.

• Усложнения с thread-safety: если ты избегаешь new, используя статические объекты, ты должен управлять thread-safety с помощью локов и семафоров, добавляя ненужную сложность.

Лучшая практика: catch по ссылке

Современный best practice в C++ — ловить исключения по const-ссылке:

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

Итого

Следуй соглашениям своего фреймворка, когда нужно, но избегай catch по указателю в новом коде. Отдавай предпочтение catch по ссылке, потому что это проще, безопаснее и это стандартный подход в C++.