Исправление next_time, (текущая версия) :
Несколько замечаний:
1) прокси реализуется для всех используемых классов, всех библиотек, но во избежание чрезмерного гемороя, кроме, возможно, 1-3 наиболее часто используемых библиотек
2) прокси позволяет сделать для каждого класса экзепшена унифицированный запись в лог, так как каждый класс выдаёт ошибку в своём формате, превращание вывода какого-нибудь std::exception().what() в пригодную для записи в лог форму. Поэтому, прокси-класс нужен всё равно
3) прокси позволяет добавлять дополнительную логику и игнорировать неинтересные ошибки, такие как выхлоп экзепшенов из std::string().substr() например. Поэтому, прокси-класс нужен всё равно
4) позволяет обрабатывать ошибки в стиле С как исключения
5) позволяет анализировать выходные данные используемых библиотек и централизованно кидать ошибки
6) позволяет централизованно добавлять другой необходимый функционал, несвязанный с обработкой ошибок, если требуется
7) вписывает иерархию сторонних классов в иерархию классов приложения
8) решает проблему зоопарка стилей наименования классов и функций
9) позволяет решать прочие проблемы, для которых изначально придуман прокси-паттерн
Поэтому, прокси нужен всё равно, в достаточно крупных проектах, использующих зоопарк библиотек. Вот этот вот мусор из трай-кетчев, да и любой другой мусор просходит из незнания принципов построения архитектуры в ООП.
Исходная версия next_time, :
Несколько замечаний:
1) прокси реализуется для всех используемых классов, всех библиотек, но во избежание чрезмерного гемороя, кроме, возможно, 1-3 наиболее часто используемых библиотек
2) прокси позволяет сделать для каждого класса экзепшена унифицированный запись в лог, так как каждый класс выдаёт ошибку в своём формате, превращание вывода какого-нибудь std::exception().what() в пригодную для записи в лог форму. Поэтому, прокси-класс нужен всё равно
3) прокси позволяет добавлять дополнительную логику и игнорировать неинтересные ошибки, такие как выхлоп экзепшенов из std::string().substr() например. Поэтому, прокси-класс нужен всё равно
4) позволяет обрабатывать ошибки в стиле С как исключения
5) позволяет анализировать выходные данные используемых библиотек и централизованно кидать ошибки
6) позволяет централизованно добавлять другой необходимый функционал, несвязанный с обработкой ошибок, если требуется
7) вписывает иерархию сторонних классов в иерархию классов приложения
8) решает проблему зоопарка стилей наименования классов и функций
9) позволяет решать прочие проблемы, для которых изначально придуман прокси-паттерн
Поэтому, прокси нужен всё равно, в достаточно крупных проектах, использующих зоопарк библиотек.